On Jul 29, 2013, at 3:34 PM, Simo Sorce <s...@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
