On Mon, Mar 31, 2003 at 01:31:50PM -0500, Matt Miller wrote:
I haven't tested it, but DOT 6.4 reports that it has:
Ability to convert a qtree to a rooted directory or convert a rooted directory to a qtree using either a Windows or UNIX client application
"...using either a Windows or UNIX client application" is the key part, here. UNIX 'mv' being one of the "client applications"... ;-) What this consists of is basically what Garrett seems to be trying to avoid:
(1) rename the directory (mv dir/ olddir/) (2) create a qtree with the name (qtree create dir) (3) copy the files over (mv olddir/* dir) (4) remove the directory (rm -rf olddir/)
The above procedure would consume 2X disk space of "dir" in step 3, and then throw EVERYTHING into a snapshot in step 4. ...not exactly what I'd call a "new feature"; presumably we were always able to do this...
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.