-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/24/2016 03:22 PM, Chris Murphy wrote:
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.
As someone who has always been curious about btrfs, thank you for this post it was very informative! This actually makes sense to me :)
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.
While /var/lib/libvirt/images is on btrfs, its put in a subvolume by default. Doesn't this mean it wont be part of the regular snapshots? - From what I understood things in subvolumes aren't subject to snapshots users take with snapper. - -- Regards, Uzair Shamim -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJWpUTEAAoJEKk4ocK8Jbkd930P/RWhNXcyHdPI8E86VUof1HEZ +Nsq4ZnmUWH2JnStiA+zys3msjbYaUrebkRUO1I5SKfNJ8Jb0MVqlYpuij6lOLdu PtA/4v1Jl1YUqqfg2A3xOBJ49yLfDWd3kPRK6fpsyZ3g7lfcjGjZNFHxKlyq26s3 VIk5jtVJsiz8eIk82O5O4jV1lyziJROYM6kb/cSgpd6mKQ4yzxo60lWuIn63bWcz pVJ4B0Lt+lbpgHfDOoWMfaPJ3eNxBYsn0iCpTCb5/z7yrIFtjJ9wsn43qTFXJ7mQ aBV6/jCyvVOew51EJjfhOTd6aJ2ZfS9ii+FSbQZ9wiQqFVHzJ8Pe8EMVnFBbtGh1 FZUhywdQV64GSCdkprGJ5ngs5sgnhESmKDDsUPQTnsrQECEq2/TW5dMFCRs9RT4n YrzNEkos4lcYhetu2Bu6q4JhI3pY3MOrT+qZaPqNfs5cFmL75/0cPxf7X88404Da HNau8UNawJ6cTNEVNmgLUqS2qEPO50DLE1Hs4cTlpi9s6wQ/bQyTNXxytOlCekAO vvUcfeSh3incr1Muf0NIChU8SIGXXhrns4oYrsOQLaiTB4n2eDs0HYrfZxnQhaEs Qo+SAL9POABFKs7s+yJis+9gUPQ8MsgO/WfJ2rpJEi/WRu8g7kUGxzjCjyjOw7iN Dm2zV60uhdX2EddCYYRC =01Z3 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org