https://bugzilla.samba.org/show_bug.cgi?id=13317
--- Comment #14 from Dave Gordon <dg32...@zoho.eu> --- (In reply to Rui DeSousa from comment #6) So you now have an example which reliably produces a bad outcome (corrupted file)? With the combination of (a) insufficient space before copying, and (b) --inplace so that no rename is needed you get no error from rsync but the file uses far less space than it should? And the contents are not as expected? Perhaps you could try this sequence: $ src=000000010000005E00000017 $ dst=arch/000000010000005E00000017 $ rm $dst $ rsync -avi --inplace --debug=deltasum2,recv2,io2 $src $dst $ touch $src $ rsync -avic --inplace --debug=deltasum3,recv2,io2 $src $dst $ md5sum $src $dst and if the md5sum shows a discrepancy then also capture a truss listing of all the syscalls made by the first run of rsync (where the destination does not exist). Rationale: I'm wondering whether ZFS if able to detect that the destination file is identical to the source file (even though it's on a different logical filesystem, it's probably still in the same pool) and merge the disk blocks (retrospectively?) So we start with a file whose logical size is 64M, but which is compressed to 19M on disk. ZFS uncompresses it on the fly and delivers 64M of data to the first rsync. rsync sequentially writes 64M, checking the success of each write. The last write should end at an offset of 64M, then the destination file is closed (and the return from that is checked). The truss listing will show how many writes were made, and whether any of them failed. ZFS will recompress (and dedup?) the written data, resulting in an unknown amount of new space being used. The second rsync will read both the source and destination files -- presumably both now being decompressed on demand -- and compare checksums. Any mismatch here will result in (parts of) the file being retransferred; obviously, this shouldn't happen if the first transfer succeeded. md5sum will check whether the files really do match. HTH, .Dave. -- You are receiving this mail because: You are the QA Contact for the bug. -- Please use reply-all for most replies to avoid omitting the mailing list. To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
