Kevin Korb <kmk at sanitarium.net> le 29/06/2023 22:43:>>> > > -i, -v, and --progress all only affect the output.Bonjour, of course I know ;-)> adds a header and footer and --progress of course adds the per-file > progress bar.Thanks, that what I wanted to know, so I keep them all.> as those 2 options are very different and I don't really see why they > should go together. >I fully agree but I don't like long options ;-p> Are you so sure rsync actually copies the file? It should correct the timestamp and tell you it did.Of that what it should do! But I'm sure not: the target is a very low-quality-and-performance USB key. I had to do it on another computer witch write on it a little less slow, otherwise I would have last forever with less than 3 kb/s. And looking the FS during the transfer, I saw the temporary files being written. And since I was using --backup, the files has been backuped... only to be replaced by exactly the same thing :-( So this disable a lot of interest in Rsync :-( Isn't there a way to disable "--whole-file"? Even if, I must admit, the source problem is the changes in timestamps. It's a mystery, it seems that there was an exact one-hour difference each time. So I suppose it's related to timezone, but how can this be? Is it the fact that the source is in Vfat(but almost always used under GNU/Linux) and target in Ext2? However, "date -r {file}" was saying "GMT+2" in both cases... I don't know and don't have time to investigate on this. Another strange thing, regarding this mailing list this time: I'm subscribed in digest mode, but this doesn't prevent some mails to be missing. For example, in the thread "copy to destination only new files" one week ago, I got the two from SE at SHCH262.com but not the one from Robin Lee Powell -- Sincerely, Stephane
Stephane Ascoet via rsync <rsync at lists.samba.org> wrote:> Kevin Korb <kmk at sanitarium.net> le 29/06/2023 22:43: > > Are you so sure rsync actually copies the file? It should > > correct the timestamp and tell you it did. > > Of that what it should do! But I'm sure not: the target is a very > low-quality-and-performance USB key ... less than 3 kb/s. And > looking the FS during the transfer, I saw the temporary files > being written. And since I was using --backup, the files has been > backuped... only to be replaced by exactly the same thing :-( > > So this disable a lot of interest in Rsync :-( Isn't there a way > to disable "--whole-file"?Short answer: Last I heard, no, for (what rsync sees as) "local" transfers. And I agree that there should be, at least when the target is a flash device -- but it might not help much with your situation. Longer answer, with details: rsync believes that, for any transfer which it sees as local (and this includes NFS, CIFS, etc. which are mapped into the local namespace although the data may in fact be accessed over a network), overwriting the destination -- even with what may be the same data -- is at least as fast as reading it first to determine whether it needs to be overwritten. This belief was usually accurate before the advent of read-mostly technologies (like flash). However, when the target is on a flash device, --whole-file creates a couple of problems: * Most flash devices, including but not limited to USB "thumb drives," can be read substantially faster than they can be written. * Even if there were no speed difference, overwriting -- even with the same data -- typically imposes wear on the flash device. (There may be a few which internally do a read-before-write, and avoid overwriting the same data.) As to your situation, I suspect you may be dealing more with transfer speed (via a USB 1.1 port?) than with read/write speed differences. The rsync assumption that reading is no faster than writing may well be accurate with this "low-quality-and-performance USB key."
> > So this disable a lot of interest in Rsync :-( Isn't there a way to > disable > "--whole-file"? >"--no-whole-file" should do it though for local copies, forcing delta transfer is not going to speed up anything in most cases. Selva -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.samba.org/pipermail/rsync/attachments/20230630/3d3f13e2/attachment.htm>