John R Pierce wrote:
John Summerfield wrote:
John R Pierce wrote:
dump 0f - /mnt/src | (cd /mnt/dst; restore rf - ) ...
And presumably, fairly quickly. I've never used dump/restore, but if it does the obvious and decides which blocks top copy, sorts the list then copies, it should be quickest of all, regardless of the data content.
dump/restore is an exact file by file copy of a filesystem, it replicates the directory entries quite exactly including all supported attributes.. I probably got in the habit of using it from Solaris, which has the rather similar ufsdump/ufsrestore.
I used to use, on OS/VS many years ago, a program called IEHDASDR. It does a track-by-track dump of a disk, in track order, of those tracks used by files and ignores tracks outside of allocated space. The only track requiring special attention is cyl 0, track 0 which contains a pointer to the VTOC (directory) which itself is a file.
My ordering the tracks, it all but eliminates seeking.
another method is
cd /source; tar clf - . | (cd /dest; tar xvf -)
That's what I said, more-or-less;-)
but not all versions of tar have the -l (--one-file-system) option (gnu tar in CentOS does, however).
oh yeah, dump will dump an unmounted filesytem too, so in fact, that could have been...
mount /dev/hda1 /mnt/dst cd /mnt/dst dump 0f - /dev/hdb1 | restore rf -
That supports my suggestion that it might, like IEHDASDR, order the block list so as to minimise seeking.
Archive programs such as tar are slow when there's a lot of data, but perform relatively well when there's not a lot of files, and doesn't copy deleted files. Tar causes lots of seeking.
dd is a straightforward sector-by-sector copy and is faster than tar when the disk is relatively full of files, but it copies deleted files and any other junk.
I think dump copies the smallest necessary volume of data, in the best possible order. Its disadvantage is that it cannot change from own filesystem to another.
There are other dump/restore programs for other filesystems.