I was told this never made it to the list. If it is the case that it made the list, but was blocked at NetApp, please excuse the noise.
Most move algorithms are:
move(old, new) if (!rename(old, new)) { copy(old, new) if (is_dir(old)) { foreach entry in old { move(old/entry, new/entry) } delete(old) }
In pre-6.4 systems, we always failed a rename() for directories and files between qtrees. In 6.4 systems, we allow renames() for files across qtrees, but not directories across qtrees.
A rename() results in the inode and none of the data nodes, being modified. Thus a 10G file gets moved as fast or as slow as a 1k file.
Allowing the rename() of the dir adds too much complexity in that we would have to handle atomicity, recovery, users modifying subdirs, multiple hard links inside the directory (detecting whether it stayed within the tree or not), and so on.
Handling just the files reduces the majority of the IO with a resulting savings in time and space. I.e., the inode is all that changed, so that the snapshot ends up with about 4 dirty blocks and not effectively 2 per data block in the file.
BTW: The FSF implementation of mv, as seen in most Linux distros, etc, has an optimization which states that if a directory can not be renamed, then its children can also not be renamed. FSF have removed that in coreutils-4.5.2 such that mv will take advantage of this new feature in OnTap 6.4.
---------------------------------------------
Chris Thompson asked:
What happens if the file being rename()'d has multiple hard links? Wouldn't this result in the inode being linked into more than one qtree?
I replied:
We don't allow the rename, which forces a copy. This in turn reduces the hard link count.
----- Forwarded message from Steve Losen -----
From owner-dl-toasters@netapp.com Fri Mar 14 06:18:05 2003
X-Authentication-Warning: fred.mathworks.com: majordom set sender to owner-toasters@mathworks.com using -f Message-Id: 200303141353.h2EDrhB04815@sasha.acc.Virginia.EDU X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 To: "Toasters" toasters@mathworks.com Subject: Re: converting a directory to a qtree In-Reply-To: Your message of "Fri, 14 Mar 2003 09:05:46 GMT." 003101c2ea09$1c676aa0$43c1869f@E689 Date: Fri, 14 Mar 2003 08:53:43 -0500 From: Steve Losen scl@sasha.acc.virginia.edu Sender: owner-dl-toasters@netapp.com Precedence: bulk
Hi,
Has anyone any experience of converting a directory to a qtree (we want to make use of the qtree to qtree snapmirror features in DOT 6.2 and greater)
There's a doc on NOW which gives two ways either do a copy, which requires enough free space (which we don't have) or to use the built in ndmpcopy feature of DOT.
There's also the possibility of doing a 'mv' on each file, although I'd be a bit concerned that this might leave the filesystem in a less than optiomal state on the filer.
I'd be interested in hearing from anyone who has done this, especially about throughput (The directories we need to convert have approx 150G of mail in them, so lots of small files, on a 840C) GB
Garrett Burke, Service Implementation & Support Manager, Eircomnet. http://www.eircom.net
As far as I know, there is no way to move a file across a qtree boundary other than to copy the file and delete the original.
Even if you use the unix "mv" command, when crossing a qtree boundary mv must copy and delete.
Since you have limited free space, you may need to copy and delete each mailbox individually. If you are using snapshots, this will obviously gobble up most if not all of your snapshot reserve, so you may need to delete all your snapshots beforehand.
Steve Losen scl@virginia.edu phone: 434-924-0640
University of Virginia ITC Unix Support
----- End of forwarded message from Steve Losen -----