On 3/5/2013 9:40 AM, David Magda wrote:
On Tue, March 5, 2013 10:02, Bob Friesenhahn wrote:
Rsync does need to read files on the destination filesystem to see if
they have changed. If the system has sufficient RAM (and/or L2ARC)
then files may still be cached from the previous day's run. In most
cases only a small subset of the total files are updated (at least on
my systems) so the caching requirements are small. Files updated on
one day are more likely to be the ones updated on subsequent days.
It's also possible to reduce the amount that rsync has to walk the entire
file tree.
Most folks simply do a "rsync --options /my/source/ /the/dest/", but if
you use "zfs diff", and parse/feed the output of that to rsync, then the
amount of thrashing can probably be minimized. Especially useful for file
hierarchies that very many individual files, so you don't have to stat()
every single one.
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
David,
Your idea to use zfs diff to limit the need to stat the entire
filesystem tree intrigues me. My current rsync backups are normally
limited by this very factor. It takes longer to walk the filesystem tree
than it does to transfer the new data.
Would you be willing to provide an example of what you mean when you say
parse/feed the ouput of zfs diff to rsync?
Russ Poyner
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss