On Sat, Jan 23, 2016 at 1:35 AM, Thomas Langkamp <thomas.lassdiesonnerein@gmx.de> wrote:
df showed enough free space, and I did not know about "btrfs fi show".
Ideally you shouldn't have to. But Btrfs still has some rough edges, and really it's quite different and the regular df command doesn't have the granularity to distinguish between types of free space that Btrfs can have: space only for metadata, only for data, and for either.
To understand, I read https://btrfs.wiki.kernel.org/index.php/Balance_Filters and the FAQ. However I do not understand much. What is all those "metadata" and what exactly does balance filter? I do understand what btrfs balance tries to fix (full file system errors), but not how or why the problem exists.
Can someone explain in less technical terms?
Basically there are two kinds of allocations in Btrfs: extents and chunks. A chunk is kinda like an uberextent or block group. Chunks are contiguously allocated from free space. Metadata (the file system itself) only gets written to metadata chunks, data (contents of files) only get written to data chunks. The ratio of metadata to data isn't fixed, it depends on file size. So there isn't a way to know in advance the proportion of data to metadata chunks, which is why they're created on demand. The problem is they aren't deallocated as efficiently as they're allocated, just because users tend not to delete files in the order they added them. As files get added and deleted, there can be many chunks that are partially full. You can end up in a situation where the file system first becomes nearly full (no unallocated space for a chunk to be created), but via file deletion it can seem there's plenty of unused space, but only for one type of chunk. The typical case is when data chunks have free space, but metadata chunks don't. Because Btrfs is CoW, there is no overwriting. So even file deletion requires free space in a metadata chunk for the delete to happen. That's why it's possible to seemingly have enough space (in data chunks) but be unable to delete because that requires free space in a metadata chunk. Currently only completely empty chunks automatically revert to unallocated space, which is somewhat recent kernel code, and can then be allocated to a different chunk type. Still not yet automatic is a limited balance that can migrate extents in nearly empty chunks to full chunks, then delete the now empty chunks so they can be reallocated as a different chunk type. That's why if this problem crops up, the solution is still a manual balance. The filters limit the balance in different ways, again for efficiency. A 'btrfs balance start -dusage=15' will limit the balance to data chunks that are 15% full, or less. That'll be pretty fast even on spinning disks, and yet it'll free up quite a few data chunks back into unallocated space from which metadata chunks can be created. Balance reorganizes the extents in chunks to be more efficiently organized. It's a kind of defragmentation at a chunk level, rather than file defragmentation which is at an extent level. There are plans to make all of this more automatic on the kernel side. It's a work in progress. Why have different data and metadata chunks? Data is replicated at the chunk level. If you check out a leaf that contains a bunch of file extent info, all of the lookups are logical addresses. It has nothing to say about what device or physical sector it's on or what the replication level is. That's what the chunk tree and device tree are for. And each chunk type can have different profiles to allocate chunks on multiple devices, with or without replication (single, raid0), and with different kinds of replication (dup, raid1/10/5/6). Balance also manages changing the profile for chunks and doing the proper replication. I'd expect most general purpose users have only system and application files on Btrfs, being regularly snapshot, with a mix of files including big file downloads on /home on XFS. That's why most people don't have this problem. But if you happen to use virt-manager and qcow2 files, by default those will go in /var/lib/libvirt/images which is Btrfs. And they are subject to snapshots. So deleting the qcow2 doesn't free up much space since a good portion of their extents are anchored in snapshots. Free up enough snapshots and it may just free up space in data chunks without completely emptying them so that their space can revert to unallocated space from which a metadata chunk can be allocated and thus avoid a seemingly bogus out of space error. So my guess is that users using virt-manager should opt for ext4/XFS entirely, or flip things around and use the XFS volume meant for /home and mount it at /var/lib/libvirt/images instead, and use a Btrfs /home. Another way around it, if you're not familiar with GNOME Boxes, it's worth a look. It uses libvirt on the backend, but its qcow2 files are stored in /home. -- Chris Murphy -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org