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 / \
