Re: hammer prune explanation

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

:Hm, how would that work, if I want it to behave like the prune command?
:I'd need to traverse a lot of filesystem trees, to just determine which
:files were deleted.
:
:Imagine:
:
:   compare /mnt with /mnt@1-hour-ago and prune deleted files.
:
:   compare /mnt@1-hour-ago with /mnt@2-hours-ago ...
:
:I wouldn't find files that were deleted in between 1-hour-ago and
:2-hours-ago. To make it work, I'd need to compare the filesystem trees
:of every possible timestamp.
:
:Regards,
:
:   Michael

    Files and directories are two different beasts.  A file can have a
    complex history associated with it, because each data block within
    the file may individually have its own history.

    Directories are a lot simpler.  The history for a directory is done
    on a directory-entry by directory-entry basis.  A directory entry can
    only be created or deleted so all we need, really, is a mechanism to
    access the deleted directory entries.  This wouldn't be an 'as-of' style
    access... it would be accessing all the active and deleted directory
    entries regardless of when they became deleted.

    Inode numbers are not reused so being able to access the deleted
    directory entry will give you the inode number, and hence the object id,
    of the deleted file(s) and sub-directories.  The pruning code is based
    entirely on the object id and doesn't care what that object's
    representation or visibility is.

    It might just be easiest to provide ioctl()'s to allow a user program
    (aka the hammer utility) to directly scan the B-Tree.  I dunno yet.

    I'm not going to worry about enhancing the utility too much until I
    get the filesystem stabilized under heavy parallel loads.  That should
    be this week.  I'm making very good progress.  It takes several hours
    of extreme testing (parallel buildworld, blogbench, pruning, AND
    reblocking all going on at the same time) to hit an assertion now
    and it is clear there are only a handful of bugs left.  The HAMMER
    source has 280 KKASSERT directives in it plus CRCs on both the data and
    meta-data so that is saying something.

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>