Marc Joliet posted on Tue, 22 Jul 2014 01:30:22 +0200 as excerpted: > And now that the background deletion of the old snapshots is done, the file > system ended up at: > > # btrfs filesystem df /run/media/marcec/MARCEC_BACKUP > Data, single: total=219.00GiB, used=140.13GiB > System, DUP: total=32.00MiB, used=36.00KiB > Metadata, DUP: total=4.50GiB, used=2.40GiB > unknown, single: total=512.00MiB, used=0.00 > > I don't know how reliable du is for this, but I used it to estimate how much > used data I should expect, and I get 138 GiB. That means that the snapshots > yield about 2 GiB "overhead", which is very reasonable, I think. Obviously > I'll be starting a full balance now.
FWIW, the balance should reduce the data total quite a bit, to 141-ish GiB (might be 142 or 145, but it should definitely come down from 219 GiB), because the spread between total and used is relatively high, now, and balance is what's used to bring that back down. Metadata total will probably come down a bit as well, to 3.00 GiB or so. What's going on there is this: Btrfs allocates and deallocates data and metadata in two stages. First it allocates chunks, 1 GiB in size for data, 256 MiB in size for metadata, but because metadata is dup by default it allocates two chunks so half a GiB at a time, there. Then the actual file data and metadata can be written into the pre-allocated chunks, filling them up. As they near full, more chunks will be allocated from the unallocated pool as necessary. But on file deletion, btrfs only automatically handles the file data/metadata level; it doesn't (yet) automatically deallocate the chunks, nor can it change the allocation from say a data chunk to a metadata chunk. So when a chunk is allocated, it stays allocated. That's the spread you see in btrfs filesystem df, between total and used, for each chunk type. The way to recover those allocated but unused chunks to the unallocated pool, so they can be reallocated between data and metadata as necessary, is with a balance. That balance, therefore, should reduce the spread seen in the above between total and used. Meanwhile, btrfs filesystem df shows the spread between allocated and used for each type, but what about unallocated? Simple. Btrfs filesystem show lists total filesystem size as well as allocated usage for each device. (The total line is something else, I recommend ignoring it as it's simply confusing. Only pay attention to the individual device lines.) Thus, to get a proper picture of the space usage status on a btrfs filesystem, you must have both the btrfs filesystem show and btrfs filesystem df output for that filesystem, show to tell you how much of the total space is chunk-allocated for each device, df to tell you what those allocations are, and how much of the chunk-allocated space is actually used, for each allocation type. It's wise to keep track of the show output in particular, and when the spread between used (allocated) and total for each device gets low, under a few GiB, check btrfs fi df and see what's using that space unnecessarily and then do a balance to recover it, if possible. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
