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)
Thanks, GB
---- Garrett Burke, Service Implementation & Support Manager, Eircomnet. http://www.eircom.net
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
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
http://now.netapp.com/NOW/download/software/ontap/6.4R1/
matt
Garrett Burke wrote:
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)
Thanks, GB
Garrett Burke, Service Implementation & Support Manager, Eircomnet. http://www.eircom.net
-- Matt Miller IT Infrastructure Team Duke University - Fuqua School of Business
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...
---- Garrett, I've done 'mv' and ndmpcopy for dir->qtree and qtree->qtree. Of course, it doesn't really matter what the source IS (dir or qtree), just as long as its not being used (written to) at the time of transfer, otherwise it becomes a game of "catchup"... ;-)
For small chunks, 'mv' or 'rsync' seems to do best; I recommend 'rsync' (http://samba.anu.edu.au/rsync/) as it doesn't change file attributes on the target files. However, in regards to 'mv' vs. 'rsync', keep in mind that 'rsync' will run on the client, COPYing files from source to target with a just a bit more NFS overhead than regular 'mv' and a lot more overhead in the beginning to "build a list of files" to sync.
For big chunks, ndmpcopy seems to be the best option. However, keep in mind there is A BUTT LOAD of overhead involved. In a ndmpcopy local->local, the local machine is performing: (1) an NDMP session for the DUMP (2) a snapshot of the tree (3) a DUMP of the snapshot (4) an NDMP session for the RESTORE (5) pipe of the DUMP of the snapshot, through the local loopback (6) a RESTORE of above's data
rather than local->remote, where each machine would only be performing 3 of the 6 steps...
Garrett Burke wrote:
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)
--
Dave Le Blanc Unix Systems Administrator Computer Science Department California Institute of Technology (626)395-2402
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.
thomas@netapp.com (Tom Haynes) writes: [...]
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.
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?
Chris Thompson Email: cet1@cam.ac.uk
thomas@netapp.com (Tom Haynes) writes: [...]
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.
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?
Chris Thompson Email: cet1@cam.ac.uk
We don't allow the rename, which forces a copy. This in turn reduces the hard link count.
-
Chris Thompson -
David Le Blanc -
Garrett Burke -
Haynes, Tom -
Matt Miller -
Steve Losen