N.J. van der Horn (Nico) wrote: > >But you need to verify and update the DB contents - which requires > >stat on all the files mentioned in the DB. In other words you might > >have to scan everything :-) > > > This already takes place while Rsync does its job, so it has not to be > done separately.
Right, but it has to be done in a separate pass if you're to compare all files with each other, not just one destination file. And you need all the RAM, too. It's like the worst case of "rsync -H". > Adding a DB to Rsync would give many more advantages, like: > - de-duplication (eliminating copies) > - alternative to "locate" > - filesystem statistics/analysis > If the structure is choosen well, it can prove to be very valuable for > other purposes also. I vaguely remember a conscious decision not to expand rsync that much. Keep the tool simple and stateless. There are already other tools which do the things you've described. > It must be possible to enable/disable checksumming when the > timestamp and size are unchanged. That clever trick is pretty > reliable in normal Rsync usage as well and earns a lot of savings. > We only do once every while full checksummed Rsyncs to be sure, but > see seldom transfers then. You could use that trick, but it's more dangerous when you're looking through the _whole_ filesystem for a matching timestamp and size, not just looking at the corresponding paths of a single file at each end. -- Jamie -- 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
