Renaming folder paths in Isilon

That was one of the main questions.

"Can we rename the path with no issue to users?"

In this case, we may have to move to a NEW folder structure which I am fairly certain is going to cause some major issues with users finding their shares, SMB links, etc.  Like -- a major headache.  Going forward this is the plan for standardization but that doesn't solve the inherited configurations which we would like to fix with minimal impact to users.

Usually about this time Dynamox would chime in and be "The Answer Man", hah.

I never liked the idea of /ifs/data/ as being the main share.  That's one extra level I felt wasn't needed and the higher up the tree we can go, the easier it goes for chargeback.

In my experience, this should work fine with no impact on the clients other than needing to reconnect. I believe that the isi smb modify command will allow you to change the path without deleting/recreating the share, so even better, but I am not quite certain of that.

I am wondering why the two steps; to my mind, those are the same thing. Unless you mean create the new path and then move the data to the new path.

So are your smb shares at the FOLDER level or at the data level?

We've never used the /ifs/data construct for data.

These are all mapped drives through active directory, SMB links.

Brian,

i have not had to do this within the same cluster. For one thing folder being moved will need to have its and subfolder quotas removed otherwise mv will be blocked. Also be careful about smb sessions, i had an instance where share was removed yet Mac users were still able to write to the old location. Once they rebooted they were redirect to the new location and they started screaming that all recently created data was gone. Well it was not gone, it was still located in the old location.  You have a slightly different scenario here but something to consider. Also think about SyncIQ polices if any.

@cariliek:  at the /ifs/DATA level.  We want to move them into a folder straight off of /ifs instead.

@dynamox:  I would remove the quotas and reapply them after the move.  What I am concerned about is the file structure as it relates to the folder paths. If I change the path, do the DFS links have to be changed as well?  And yes, FULL SYNC is going to required again but we'll have backup copies in the meantime.  I really need to answer quickly as to how we can do this safely, effectively with minimal impact to users.

Brian_Coulombe_Disney,

Working to see if I can find away to do this with minimal impact.

How are your users connected to the shares? via a mapped drive or utilizing UNC path?

Dynamox,

Some good things to think about there as well. Quotas and SyncIQ policies, I did not cover those in the test I did but, they would need to be addressed as you said. Good info!!

In regards to the Mac clients, I would assume that killing lwio would force them to the new share path. Unfortunately I do not have a Mac client to test on.

Ah, I misunderstood. Yeah, there's no way you're getting away with this without the SMB clients disconnecting/reconnecting.

Dynamox,

Yup, all SMB client connections will be effected from killing lwio.

First paragraph of my response covers that

"Or I can kill lwio to force all SMB clients connected to the cluster to reconnect."

Shane,

isnt' killing lwio will disrupt access to the entire cluster ? I am not sure how granular Brian's migration is going to be but something to be aware off.

Mac clients are PITA , i remove the share, kill the session for the Mac client (using isi smb sessions delete) yet they still reconnect and are able to write to the share (even though the share is gone ! ) . I told my helpdesk to tell all Mac clients to reboot.  We had to go through this hoopla while migrating from an old 6.5 cluster to 7.1. 

Brian_Coulombe_Disney,

Simply using mv and changing path to share with a map drive does not work. I get an error stating that the :\ refers to a location that is unavailable....

Being that SMB is looking for the old path of the map drive, and will continue to do so until forcing a reconnection.

So I would need to disconnect and reconnect to have the mapped drive point to the new path on the cluster. Or I can kill lwio to force all SMB clients connected to the cluster to reconnect.

I don't think there is away to do this seamlessly, without having to disconnect or having clients mapping a new drive with the new share path.

Maintenance window would be needed to complete this. Even though the users would only experience a hiccup (similar to when an IP is moved with/by smartconnect)

Heres the process I used to completely test this and, the commands use to complete the mv and SMB path change:

create /ifs/SMB

isi720z-1# cd /ifs

isi720x-1# mkdir SMB

isi720x-1# cd SMB

isi720x-1# pwd

/ifs/SMB

I created 10 files in the directory just to make sure everything moved and the share was still accessaible

isi720x-1# ls

file1  file10 file2  file3  file4  file5  file6  file7  file8  file9

Made an SMB share for this test, wide open permissions for testing purposes: (Note Path)

isi720x-1# isi smb shares view --share=SMB
                                     Share Name: SMB
                                           ***Path: /ifs/SMB***
                                    Description: SMB share
                     Client-side Caching Policy: manual
Automatically expand user names or domain names: False
Automatically create home directories for users: False
                                      Browsable: True
Permissions:
Account  Account Type  Run as Root  Permission Type  Permission
----------------------------------------------------------------
Everyone wellknown     False        allow            full
----------------------------------------------------------------
Total: 1

          Access Based Enumeration: No
Access Based Enumeration Root Only: No
             Allow Delete Readonly: No
              Allow Execute Always: No
                     Change Notify: norecurse
                Create Permissions: default acl
             Directory Create Mask: 0700
             Directory Create Mode: 0000
                  File Create Mask: 0700
                  File Create Mode: 0100
                    Hide Dot Files: No
                          Host ACL: -
                 Impersonate Guest: never
                  Impersonate User:
                 Mangle Byte Start: 0XED00
                        Mangle Map: 0x01-0x1F:-1, 0x22:-1, 0x2A:-1, 0x3A:-1, 0x3C:-1, 0x3E:-1, 0x3F:-1, 0x5C:-1
                  Ntfs ACL Support: Yes
                           Oplocks: Yes
                      Strict Flush: Yes
                    Strict Locking: No

Mapped a network drive on my windows PC to /ifs/SMB

Made I directory to mv data over to:
isi720x-1# mkdir cluster1
isi720x-1# cd cluster1
isi720x-1# pwd
/ifs/cluster1

Nothing in the directory

isi720x-1# ls

I will mv /ifs/SMB to /ifs/cluster1/ and immediately make a change to the path location of the share and kill lwio

isi720x-1# mv /ifs/SMB /ifs/cluster1/ ;  isi smb shares modify --share=SMB --path=/ifs/cluster1/SMB ;killall lwio

Just before running this I opened one of the files and started editing it on /ifs/SMB and wrote a few things "HELLO WORLD" once the mv and path change complete I will attempt to save the document after the migration.

I had no issues saving the document after completely moving the files and the path of the share to the new directory.

However killing lwio will effect any writes that are currently happening to the cluster, and will need to be attempted again.

Showing that everything moved as expected

Old directory is gone
isi720x-1# ls /ifs/SMB
ls: /ifs/SMB: No such file or directory

New directory has all the files
isi720x-1# ls /ifs/cluster1/SMB
file1  file10 file2  file3  file4  file5  file6  file7  file8  file9

SMB share is pointing to the new directory.
isi720x-1# isi smb share view SMB
                                     Share Name: SMB
                                           ***Path: /ifs/cluster1/SMB***
                                    Description: SMB share
                     Client-side Caching Policy: manual
Automatically expand user names or domain names: False
Automatically create home directories for users: False
                                      Browsable: True
Permissions:
Account  Account Type  Run as Root  Permission Type  Permission
----------------------------------------------------------------
Everyone wellknown     False        allow            full
----------------------------------------------------------------
Total: 1

          Access Based Enumeration: No
Access Based Enumeration Root Only: No
             Allow Delete Readonly: No
              Allow Execute Always: No
                     Change Notify: norecurse
                Create Permissions: default acl
             Directory Create Mask: 0700
             Directory Create Mode: 0000
                  File Create Mask: 0700
                  File Create Mode: 0100
                    Hide Dot Files: No
                          Host ACL: -
                 Impersonate Guest: never
                  Impersonate User:
                 Mangle Byte Start: 0XED00
                        Mangle Map: 0x01-0x1F:-1, 0x22:-1, 0x2A:-1, 0x3A:-1, 0x3C:-1, 0x3E:-1, 0x3F:-1, 0x5C:-1
                  Ntfs ACL Support: Yes
                           Oplocks: Yes
                      Strict Flush: Yes
                    Strict Locking: No

Mapped drive is fully functional after completing the above. Without having to remap the drive.

***Edit to the command to mv and change share path would be as follows as I was testing this on a single node

isi720x-1# mv /ifs/SMB /ifs/cluster1/ ;  isi smb shares modify --share=SMB --path=/ifs/cluster1/SMB ; isi_for_array killall lwio

javascript:;Editing: I had a ton of screenshots that didn't come through when attached to an email.

Group, there is a bit of trickery here.  Basically if you had a user that had open /ifs/data/home/joesmith and you move it to /ifs/clustername/accesszonename/homedirs/joesmith, even without  moving the share, domain\joesmith who is connected won’t lose access.  Why you ask?  (cause I know someone will).

Repro Time:

Create the directory, and the share, and let domain admins have their way with it to set NTFS ACLs.

I created this user, and gave them rights to the directory in question, and rights to logon to a terminal server to make it more real:

Now I’ll create some data in that directory for our user to read.

So we have 1GB of data excluding parity:

Let’s set a 10GB directory quota at the top level and a 2GB per-user quota to make it more interesting:

Verifying that the quotas were created correctly

They were, so now where to move it?  As mentioned by Brian, a path like /ifs/clustername/accesszonename/ is our best practice; you can read more about it in the external network connectivity guide: (See Page 23 for this topic)

http://bit.ly/1HIMeVg

I’ll now verify to control this tightly what node our user ended up connected to when he logged into the terminal server:

So the answer is node 2.

So now I’ve opened two of the test files on the terminal server, and you can see it, but notice that ID (think of it as a file handle/sessionID):

So now let’s move it, and see what happens… What do you think will happen?

Notice the before and after.  Look specifically at the ID for the before and after….  Also take note that I did not use trailing slashes in the move, that way it’s just updating a single inode for the directory, not moving the content of the directory.

Then I opened another file that is actually now in the new path; It looks like it never moved, right?  But it did, and IO is still working without an issue for a client that’s already connected, you can see file.7 in the above screenshot, it opened correctly

So now, let fix the other problem, moving the share, because un-doubt-ably clients trying to connect between when you move the directory and when you move the share will have problems.  Now check out the path, it updated, but look again at that ID… 4865602, still hasn’t changed, the user is still connected and can still read and write files.

Notice this file.17… still working (the client never logged out, disconnnected, reconnected, no services were stopped, period.

Well you say that’s awesome, now what about those quotas?

Still intact, just like you would hope and expect. 

So what didn’t I test here?

Snaps, Replication, and NFS Exports, quotas on the parent of directory that you’re moving… anyone else want to comment on those others?

Would I do this in the middle of the day in production?

No, of course not, but as you can tell the impact is greatly minimized through use of the proper procedures and testing.

Hope This Helps,

~Chris

Chris Klosterman

chris.klosterman@emc.com

twitter: @croaking

Advisory Solution Architect

Offer and Enablement Team

EMC²| Emerging Technologies Division

if you attempted to provide pictures, they did not make it. Hard to follow your response without them.

Brian_Coulombe_Disney wrote: @dynamox:  I would remove the quotas and reapply them after the move.  What I am concerned about is the file structure as it relates to the folder paths. If I change the path, do the DFS links have to be changed as well?  And yes, FULL SYNC is going to required again but we'll have backup copies in the meantime.  I really need to answer quickly as to how we can do this safely, effectively with minimal impact to users.

DFS links point to shares,  so as long as share name remains the same and stricture within the share does not change you don't have to mess with DFS.