This post is more than 5 years old
6 Posts
0
12985
Moving folders within Isilon using CLI
We need to move some files from one location to another within our Isilon cluster. These are department folders ranging from 3GB up to 20+GB in size. I have been moving them via my desktop's Windows Explorer via Cut and Paste during off hours to lessen any user disruption. Is there an easier/quicker way to do this via CLI? For example: we are moving departmentA's folder from \\Isilon\ifs$\Spokane\S\DepartmentA to \\Isilon\ifs$\cluster\Spokane\DepartmentA
kipcranford
125 Posts
1
February 25th, 2015 11:00
Right. You can't do a simple rename between quota domains; it requires a copy/delete operation. Renames are essentially instantaneous, copy/delete can be quite time consuming depending on the content.
--kip
dynamox
2 Intern
2 Intern
•
20.4K Posts
0
February 25th, 2015 10:00
you can use "mv" but be aware of quota limitations ..there are certain limitations if source/target have quotas enabled.(someone can provide the details ..i can't remember from the top of my head)
cadiletta
106 Posts
2
February 25th, 2015 14:00
When you do a cut and paste through Windows, you are moving data around through the external network interface, through your windows machine and then back onto the cluster for this movement.
By using a direct 'mv' command on the cluster this data will move around within the cluster, better utilizing the internal functions of the cluster to get that done more efficiently.
It is worthwhile to run a test though, as the others have said, if there are quotas, permissions, zones, or other unforseen details of these files, give the mv a try. Inspect the resulting files at the target in comparison to what you've been copying with Windows. Same permissions? Quota issues? Other issues?
Peter_Sero
1.2K Posts
1
February 25th, 2015 20:00
Don't need to actually copy stuff;
linking just does it even in presence of quotas:
cp -Rl source target (that's an "ell" after the R)
Remove the source afterwards, using rm -rf or a TreeDelete job.
In case you need to roll back, just remove the target side.
hth
-- Peter
dynamox
2 Intern
2 Intern
•
20.4K Posts
0
February 26th, 2015 11:00
here is one scenario where i am not sure how this would work. We have two Isilon clusters, prod application resides on cluster A, dev application resides on cluster B.
Prod application directory is replicated to cluster B once a day. From time to time we need to refresh dev instance with data from prod. Since my prod data is already on cluster B, i use syncIQ and copy the data internally. Basically i use my SyncIQ read-only target of prod data as my SyncIQ source for this internal copy. This directory is getting bigger and bigger so this syncIQ copy takes longer and longer every time we have to refresh this dev environment. Peter suggestions would be great but i don't think that would that work if my source is read only and my source is not going away and will be changing during next SyncIQ cycle ?
crklosterman
450 Posts
2
February 26th, 2015 11:00
All,
One item to keep in mind here is that if you move a directory outside of the share path, to another share, it may not immediately cause any client disconnects. This is because what the user has open is actually the filehandle, not the path, and moving the directory doesn't change the filehandle. So until the SMB session dies, access may still be available to users that have open sessions in one manner or another. So test this, and if you need, you can use isi smb sessions perhaps with isi_for_array to force-close sessions.
~Chris Klosterman
Senior Solution Architect
EMC Isilon Offer & Enablement Team
email: chris.klosterman@emc.com
twitter: @croaking
dynamox
2 Intern
2 Intern
•
20.4K Posts
0
February 26th, 2015 11:00
as you said it's linking, any changes to target are immediatly reflected in the original source. In case somebody hoped it's an instance copy feature
Peter_Sero
1.2K Posts
0
February 26th, 2015 20:00
Absolutely! This linking maneuver usually is a big time saver, but client access should be stopped during whatever method of reorganizing shares or subfolders.
-- Peter
Peter_Sero
1.2K Posts
0
February 26th, 2015 20:00
> Peter suggestions would be great but i don't think that would that work if my source is read only and my source is not going away and will be changing during next SyncIQ cycle ?
The read-only is the problem -- compare with snapshots (don't have SyncIQ here):
One cannot link a file from snapshot to a regular directory.
The attempt will result in a "read-only file system" error, because
linking will attempt to increase the link count on the file's inode
inside the snapshot!
Try it out with a SyncIQ read-only target (as link source),
I would assume it will be just the same.
In case of snapshots, cloning files (cp -c) does help, because a new
"writable" inode is created per file, and only unchanged /data/ blocks are shared.
Again you would need to try it with SyncIQ targets.
Doing cp -c recursively will require scripting, it cannot be combined with cp -R.
Ultimately, one might want to update a tree of cloned files incrementally
rather than rebuild it from scratch; like "rsync with clones".
Left as exercise to the reader for now....
-- Peter