On Jul 29, 2013, at 3:34 PM, Simo Sorce <simo(a)redhat.com> wrote:
btrfs consumes space on each write to the same block.
If you have a 10GB file system with a 5GB, existing log file and overwrite it twice in
place, you will run out of space.
It's a sufficiently confusing example, that I almost wish df (the typical user-space
tool to learn of free space) would lie for btrfs volumes by subtracting 15% in the report.
The raid1/10 case is even more confusing, but only because users now expect to be lied to
that they have 1/2 the storage space compared to what they purchased. Btrfs is telling the
whole truth about the total available storage and that data is taking twice the
allocation.
So again it's managing user expectations. Maybe df should persist in lying somehow
(although difficult with mixed raid levels in a single volume), and the more lower level
stat and btrfs tools should tell the deeper story?
There is no magic pony here for you - if you configure thin, you mean
to use it to lie to the users and their file systems for a valid reason.
And not new. Qcow has allowed the situation for some time.
A legitimate concern is how the file system behaves when its virtual storage suddenly runs
out of backing storage space; that it can fail semi-gracefully (i.e. without file system
corruption, even if there would be data loss).
Chris Murphy