User: Password:
|
|
Subscribe / Log in / New account

Avoinding disk-full problems

Avoinding disk-full problems

Posted Jun 1, 2012 12:37 UTC (Fri) by ablock (guest, #84933)
In reply to: Avoinding disk-full problems by pjm
Parent article: Atime and btrfs: a bad combination?

That would destroy the idea behind snapshots. A snapshot should always be extremely cheap if you don't change anything. If we reserve the space at creation time, the whole idea of snapshots gets lost.


(Log in to post comments)

Avoinding disk-full problems

Posted Jun 1, 2012 15:07 UTC (Fri) by drag (subscriber, #31333) [Link]

Yes. I want to be over allocate disk space.

Avoinding disk-full problems

Posted Jun 1, 2012 17:21 UTC (Fri) by faramir (subscriber, #2327) [Link]

If I understand how this works, it is only the most recent snapshot for which this "massive reads generate massive writes" event can happen. So any preallocation only has to exist for the most recent snapshot.

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.

Avoinding disk-full problems

Posted Jun 2, 2012 18:52 UTC (Sat) by drag (subscriber, #31333) [Link]

> As to snapshots being "cheap", that can refer to two different things: storage requirements OR execution time.

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