DragonFly kernel List (threaded) for 2008-10
Re: New hammer utility feature in HEAD: 'hammer cleanup'
Matthew Dillon <email@example.com> 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.
> 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.