Hi,
For what it's worth, I always specify my source and target paths as absolute, ending in a slash (/). This has saved me from sneaky mistakes many a time. Next to that, I don't know if your target filesystem is supposed to be an exact copy of the source, but you did not specify --delete which results in rsync not touching any files in the target filesystem that do not match files in the source (ie. file foo exists in target and stays there. with --delete it would be removed). I would secify a sync between an target and source filesystem as follows:
rsync -avPH --delete /sourcefs/directoryA/ /targetfs/directoryA/
I've seen differences in fs sizes when the blocksize or type of filesystem differ from one-another. Always wondered what the exact underlying reason for it was (ie. I don't have a more exact answer ;-)
Kind regards,
Rubin.
Les Mikesell wrote:
John R Pierce wrote:
Sven wrote:
Hi folks
We migrated storage from local disk to SAN with:
# rsync -avz /mnt/lvol00045/* /lvol00045
Why there is a difference in size? How to explain this? Do we have inconsistency? What we did wrong?
[...] /dev/mapper/vg01-lvol00045_old 10321208 3930336 6286016 39% /mnt/lvol00045 [...] /dev/mapper/vg01-lvol00045 10321208 3163852 6633068 33% /lvol00045
did rsync copy .* hidden files ?
do the two file systems have the same block size?
Rsync would copy hidden files when recursing as a side effect of the -a option. However, the shell is going to expand that '*' before rsync sees the command line and miss any hidden files in the top level directory. I'd probably have done: cd /mnt/lvo100045 rsync -avH . /lvo00045 instead. That gives rsync a directory as a starting point without having to remember the quirks of whether it will or won't create a subdirectory of that name on the target. It also doesn't make sense to use -z for a local file copy and you might need -H if you have hardlinked files on the filesystem.