On 14Dec2012 14:04, Fernando Lozano <fernando@xxxxxxxxxxxxx> wrote:
| I'm seeing the file three walk is taking too long, just to find that
| most files weren't changed, even relying on last modification time,
Just out of curiosity, what sort of scale are you dealing with (file
sizes, file counts, gross filesystem content size, rsync elaspsed time
for a tree walk)? I'm using rsync based backups and the file tree walks
work for my scale but I'm fairly sure it is smaller than yours.
| that
| if I could get a list of blocks to back up it should be faster (less
| disk seeks).
|
| It shouldn't be too hard to implement a deamon using inotify and some
| queueing strategy to deal with changed file blocks, add metadara, then
| compress and send elsewhere.
For something more tractable, suppose you had an inotify daemon that
recited the paths of modified files to a log. At backup time you rotate
the log, then issue an rsync using --files-from (or equivalent tar
command or whatever) to grab the files known to be changed.
This may scale poorly if you have very large files with small changes,
but it solves the file tree walk bottleneck.
Cheers,
--
Cameron Simpson <cs@xxxxxxxxxx>
No team manager will tell you this; but they all want to see you
come walking back into the pits sometimes, carrying the steering wheel.
- Mario Andretti
--
users mailing list
users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org
