Executive summary of question:
Is there a fast, efficient way to move a directory tree from one qtree to another? (Can a rename/mv simply relink across qtrees?)
Detail:
(We are new to NetApp, so this might be a FAQ: if so, just point me in the right direction.)
We soon need to move the home directories of a few thousand users from a couple of Sun/Solaris NFS/Samba fileservers onto a NetApp. On the old Sun fileservers, these users are subgrouped using one scheme (into about 100 subgroups); on the new NetApp they'll be redistributed into about five qtrees.
Ideally, we would simply pull them across the network (a long evening's work!) dumping them into one qtree on the NetApp. The second step would be to redistribute them into their new qtrees and, for us, conceptually straightforward because the homedirectory names can be pattern-matched into corresponding qtrees. In UNIX-speak, the equivalent of: mv qtree_tmp/<...>/dir_pattern_1 qtree_a mv qtree_tmp/<...>/dir_pattern_2 qtree_b (about five commands, one per qtree).
In UNIX-land, a "mv" within a volume is a fast operation, simply relinking from one parent directory into another; whereas an "mv" across volumes is (of necessity, of course) a much larger data-copying operation.
On the NetApp/WAFL is such a move across qtrees a simple relink or is it a data-copying operation? Is there a NetApp command to move/rename a directory-tree? If so, what?
Not having found a NetApp command, I experimented with an "mv" from a UNIX box which had the volume NFS-mounted. But this took a long time so, I presume, was doing a data-copy, rather than relink.
(Hope I explained that reasonably clearly!)
On Tue, Jul 16, 2002 at 11:05:08AM +0100, David Lee wrote:
Ideally, we would simply pull them across the network (a long evening's work!) dumping them into one qtree on the NetApp. The second step would be to redistribute them into their new qtrees and, for us, conceptually straightforward because the homedirectory names can be pattern-matched into corresponding qtrees. In UNIX-speak, the equivalent of: mv qtree_tmp/<...>/dir_pattern_1 qtree_a mv qtree_tmp/<...>/dir_pattern_2 qtree_b (about five commands, one per qtree).
Why don't you mix those two and dump to proper qtrees already?
p.
Ideally, we would simply pull them across the network (a long evening's work!) dumping them into one qtree on the NetApp. The second step would be to redistribute them into their new qtrees and, for us, conceptually straightforward because the homedirectory names can be pattern-matched into corresponding qtrees. In UNIX-speak, the equivalent of: mv qtree_tmp/<...>/dir_pattern_1 qtree_a mv qtree_tmp/<...>/dir_pattern_2 qtree_b (about five commands, one per qtree).
As the other poster stated, I would recommend running a script which combined everything into one step. I also recommend using rsync. You can rsync the data live right now or a few days before the migration. Then when the actual cutover takes place, lock the home dirs (no more writes) and rerun the rsync command. It will scan over the files and only copy those things that have changed.
On the NetApp/WAFL is such a move across qtrees a simple relink or is it a data-copying operation? Is there a NetApp command to move/rename a directory-tree? If so, what?
I don't know if this is supported by Netapp, but it works. At your filer prompt, run "java netapp.cmds.jsh". Then type help. It mentions normal Unix commands like ls, cat, rm, cp, mv. I believe this mv would be faster than mv from the Unix client. When you're done, type "exit" and it will put you back at the filer prompt.
/Brian/
On Tue, 16 Jul 2002, Brian Long wrote:
Ideally, we would simply pull them across the network (a long evening's work!) dumping them into one qtree on the NetApp. The second step would be to redistribute them into their new qtrees and, for us, conceptually straightforward because the homedirectory names can be pattern-matched into corresponding qtrees. In UNIX-speak, the equivalent of: mv qtree_tmp/<...>/dir_pattern_1 qtree_a mv qtree_tmp/<...>/dir_pattern_2 qtree_b (about five commands, one per qtree).
As the other poster stated, I would recommend running a script which combined everything into one step. I also recommend using rsync. You can rsync the data live right now or a few days before the migration. Then when the actual cutover takes place, lock the home dirs (no more writes) and rerun the rsync command. It will scan over the files and only copy those things that have changed.
Hmmm... rsync (rdist) ... good idea.
Why didn't I think of that? Especially as I'm already using "rdist" for the applications. Perhaps because I had an overriding concern about the regrouping aspect of our several thousand accounts from one set 100 subgroups "/home/oldserver/subgroup_1/user_a" into a new set of about five subgroups "/home/newserver/qtree_I/user_a": in effect, a rehashing (not a coagulation of old groups).
Anyway, I'm experimenting with "rdist" (sorry, not "rsync"!) at this moment, and it's looking promising.
Thanks, to you and the other folk who replied on-list and off-list. Much appreciated.