Robin is right. Read back verification has lost its meaning since old days when we used extremely unreliable media or transports. Who writes to floppies anymore? In those old days you could/should use any copy program with a -v verify flag. But read-back wore down your floppy faster, so in the end... Transfer by TCP and like protocols sense errors and do repair "on the fly". (Re-sent packages happen, and you never even notice.) If not correctable (only if connection breaks) you really receive an error that is sensed and passed through all layers to the application. And if this is not really weird programming, the message will be caught by the user or calling program. The same is true for modern hardware. Your s.m.a.r.t HDD informs the system of problems. Since 1980s or so I NEVER had an error displayed by a direct (immediate) verification read. At some LATER time your aged CD might become unreadable... To make it short: Technical failure WILL be noticed by modern systems. It is admin's job to react.
Nowadays 99% of data loss is neglect in programming or user attention. And the last may even occur with a verification message. Do you write your script so you REALLY receive an error if one happens? Even operating worn/aged HW is not remedied by read back, but in fact a human neglect. Still, flushing all volatile memory at the end of a write process is a good idea. A proper sync does that, a read back does not. Au contraire, it will happily read cached data. Am 17.02.23 um 17:51 schrieb Robin Lee Powell via rsync:
That's not the same as a read-back write verification. I believe that in general, rsync assumes that the disk actually wrote whatever it was told to write.
-- 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
