xfs_copy would really be the ideal tool to do this, but last I heard it
still needs some work to get it fully ported to linux.
I just make an XFS filesystem on the second disk and use rsync to copy
all of the files over, but wonder if that is "safe" for extended file
attributes. Since this works on top of the fs cache, you shouldn't run
into any "hidden" changes, but you could have problems with files that
are in the process of being modified.
I think the most efficient way would be to make an XFS filesystem on the
second partition, then pipe xfsdump to xfsrestore to the second
partition, and that should preserve all of the extended file attributes
as well. I have tried this, but ran into weird problems with file
attributes being different on the copy, haven't had the time to really
experiment and try to reproduce the problem.
Using dd is very slow because you aren't just copying used inodes, you
are copying all of the "empty" space as well which can be very time
consuming for a large filesystem.
If you're going to be doing larger scale cloning, I think you're better
off setting up RAID1 to begin with then use raidhotadd to sync up a new
copy. I have a pair of semi-redundant servers, and I upgraded one
server then used this method to "upgrade" the second server and it
worked very well. I don't know if you take much of a performance hit,
though, if you have a single-disk system and run the RAID1 in degraded
mode vs. having just a normal filesystem without RAID1.
Yannick Ribau wrote:
> So it might work if I boot from a rescue CD with a kernel supporting
> xfs, then do the dd command without mounting the partitions (using
> /dev/hda...) ?
--
"Jonathan F. Dill" (dill@xxxxxxxxxxxx)
CARB IT Coordinator
Experimental Support Site http://concept.umbi.umd.edu
|