Matthew Dillon <[EMAIL PROTECTED]> wrote: > :When run on a filesystem without snapshots, cleanup seems to create a > :single snapshot and start pruning. > :>From the man page I would have expected a snapshot per day (also for > :previous days). > :I think with the current setup one can loose history if cleanup is > :not run often enough. > : > :Regards, > :Johannes > > Yes, I see what you are saying. Since the idea is to run cleanup > from cron the issue only really applies to the initial cleanup on > a filesystem that has never been cleaned before. I think the > current behavior is reasonable if a bit unexpected, but it is really > only a one-time thing. > > It is possible to generate backdated snapshots for a filesystem that > has never been pruned, or to generate backdated snapshots from the > most recent snapshot onward (if, say, you had stopped cleaning for > several days). > > HAMMER doesn't record the highest transaction id pruned though and > creating snapshots for older transaction ids (in areas already pruned) > will not give you a consistent snapshot so 'catch-up' snapshots might > not reflect consistent views of the filesystem. In otherwords, > the catch-up snapshots might not contain the expected results. > > -- > > I don't plan on doing this but if someone has a coding itch I can tell > you how to implement it: > > * Initiate a mirror-read from the starting transaction id. That is, > the transaction id of the most recent snapshot, or (1) if no snapshots > are present. NOTE: it is not possible to obtain consistent snapshots > for any period prior to the point where a filesystem has been pruned > via 'prune-everything'. > > * Collect transaction ids and datestamps (the B-Tree elements have > both). Create a histogram by using the datestamps to sort the > transaction ids into hoppers, using a 10 minute granularity. > > * Select transaction ids in the rough time periods you wish snapshotted, > try to look for a period of quiescence so the snapshot is consistent > (with the above caveat: a consistent snapshot is not possible for > any period of time covered by a prior pruning operation).
Would it be a valid assumption that leaf nodes with higher transaction ids have higher (later) timestamps? In that case one could perhaps do a binary search to find a transaction id close to a given timestamp. Cheers, Johannes
