Re: New hammer utility feature in HEAD: 'hammer cleanup'

[Johannes Hofmann <johannes.hofmann@xxxxxx>]

Matthew Dillon <dillon@apollo.backplane.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.
> :
> :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