Avoinding disk-full problems
Posted Jun 1, 2012 15:07 UTC (Fri) by drag (subscriber, #31333)
Posted Jun 1, 2012 17:21 UTC (Fri) by faramir (subscriber, #2327)
As to snapshots being "cheap", that can refer to two different things: storage requirements OR execution time. Preallocation might not be cheap
in terms of storage, but it should be fairly cheap in execution time.
If I'm right about only needing preallocation for the most recent snapshot, you might be able to just handoff the preallocated space from snapshot to snapshot reducing the execution cost. As for reserving space for this, it would be kind of like the X% reserved for "root" which many filesystems have/had (which was often actually done to reduce fragmentation). The preallocation here would be to preserve functionality (i.e. working atimes) even when the filesystem was "full".
Now as to why BTRFS needed such a large amount of space relative to the size of the filesystem, in the example, that would seem to be an issue with the design of BTRFS and how it interacts with traditional Unix filesystem functionality. As others have suggested storing atimes separately (perhaps just for the "trunk") might work. Perhaps better would be to give the trunk a "current" atime allocation in addition to the standard one. Updates would go to both the current data structure (after copying) as well as the atime only structure up until the disk was full. OTOH, this is getting complicated. No something to figure out in a couple of minutes.
Posted Jun 2, 2012 18:52 UTC (Sat) by drag (subscriber, #31333)
I think it refers to _both_.
Plus it's tough to pre-alocate when you have no idea how much space you are actually going to have to end up using.
Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds