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)

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? 

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

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 ?

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

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

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 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