[Dirvish] Moving a Dirvish Vault

Brian Martin Brian at MartinConsulting.com
Sat Jun 3 02:26:16 UTC 2006


> 
> Very true, so I use tar.  tar will preserve hard links, and since it 
> just streams the data as it gets to it there's no pre-computation of 
> anything to consume time or memory.  With appropriate uses of 
> pipes and 
> ssh, you can grab the data from one machine and extract it to 
> another. 
> Sorry I don't have a command line handy for you, but I've used it for 
> just this purpose for a 200+ GB vault, where each of the ~100 images 
> would have individually consumed 100+ GB.  Other than taking 
> forever due 
> to the network involved, it had no issues.  One thing that's 
> a potential 
> concern is that it can't be interrupted and restarted (like 
> rsync could, 
> if it worked), you'd have to start again from the top.
> 

Here's my tar command for duplicating all files in directory "/abc" to
directory "/def" (substitute appropriate full paths as necessary -- they
don't need to be peers, either).

	(cd /abc && tar -cf - .) | (cd /def && tar -xf -)

I haven't tried it with Dirvish in particular, but I use it often.  Note
that some published examples show this using ";" instead of "&&".  That
works fine unless /def doesn't exist or got typo'd.  Using ";" in this case
will cause /abc to get untarred into your current directory (yuck), whereas
using "&&" will cause the whole thing to stop.  As you can imagine, I
learned that the hard way.

And as an alternative, you can consider this approach, which I often use
often when moving something from one hard drive to another.

1) Make sure the source and target partitions are unmounted.  Obviously the
target has to be at least as large as the source.
2) Use "dd" to copy the source to the target.  I always use "hdparms" to
make sure that DMA is on (much faster).  You can do:  

	dd if=/dev/hda1 of=/dev/hdc1

which will use a 512 byte block.  I haven't ever found out if there are any
restrictions on using larger block sizes, but I've used an additional
parameter of "bs=4096" or "bs=5120" without any apparent ill effects.
3) Now your data is on the target partition, but the file system isn't any
bigger.  Use one of the "resize" commands or qparted to grow the file system
into the rest of it's new partition.  For example "resize_reiserfs
/dev/hdc1" or "resize2fs /dev/hdc1".  I also use this approach with a
Knoppix disk and "ntfsresize" all the time to grow Windows partitions.
Works great!

                    -Brian Martin




More information about the Dirvish mailing list