Question about FSHammer getting full

[Simon 'corecode' Schubert]

Thomas Nikolajsen wrote:
    Thomas, its definitely possible to do both those things.
    Pruning on a per-file basis can be done by carefully specifying the
    key range in the ioctl call to just cover the desired object id (inode number).
    Determining how much space the snapshots use can be accomplished by
    scanning the B-Tree.  Some form of the mirror-read ioctl which flags
    the mirror read code to just send the B-Tree records without any of
    the related bulk data (HAMMER_MREC_TYPE_PASS).
    Then the hammer utility can use the mirror-read ioctl with this new
    flag and collect the usage information into buckets based on the
    delete_tid.  The utility can use the prune command's snapshot gathering
    procedures to figure out where the bucket demarkations are.
    I think it all can be done with only a modest amount of work and it
    would be awesome if you did it!
This sounds really interesting, I will look into this!
I think it is not as easy, because we want the current state to be the 
reference, and have the usage of the snapshots show what would be free'd 
when the snapshot was removed.  So old, unmodfied data has to be charged 
to the current usage and not to the snapshot that first contained it.

cheers
  simon
--
  <3 the future  +++  RENT this banner advert  +++   ASCII Ribbon   /"\
  rock the past  +++  space for low CHF NOW!1  +++     Campaign     \ /
Party Enjoy Relax   |   http://dragonflybsd.org      Against  HTML   \
Dude 2c 2 the max   !   http://golden-apple.biz       Mail + News   / \