outcome of big rsync. Puzzling
John Van Essen
vanes002 at umn.edu
Mon Dec 20 17:45:11 GMT 2004
On Sun, 19 Dec 2004, <mlaks at verizon.net> wrote:
> source vs destination in bytes
> a) 20480 vs 34922496
> b) 28672 vs 24576
> c) 61718528 vs 61714432
> d) 157790208 vs 157786112
> each directory consists of subdirectories of medical images in dicom format.
> Most interesting to me was case a) where the preimage was smaller than the
> in fact, when i looked at the data in the directory a) in the destination,
> they seemed to be consistent dicom files. ie they seem to open with dicom
> file parsers. While the preimage directory in the case of a) i actually has
> no files to be found in the subdirectory. Thats why it is so small.
> I should mention that I did once have a problem with this server and I once
> had to run fsck.ext3 on the raid drive to fix some linked files.
Had you already run rsync before encountering that disk problem?
Maybe the target has junk in it that you fixed/deleted on the source?
Are you running rsync with --delete? It will remove leftover garbage.
Add --dry-run to see what rsync would delete without actually doing it.
The other three cases where the size is smaller by 4096 bytes are very
likely from source directories that used to contain a larger number of
files, but no longer do, so the target directory needs 1 fewer block
to hold the entries for the current files.
More information about the rsync