Am Samstag, 17. Dezember 2011 schrieb Hugo Mills: > On Sat, Dec 17, 2011 at 12:09:56PM +0100, Martin Steigerwald wrote: > > I think I will scrub / balance / defragment the filesystem after a > > backup. But I am not sure in what order. > > > > I understand that defragment defragments files. But then what does > > balance do? For RAID setup I have seen it distributing data evenly > > across drives when I echo > /sys/block/sda/[…]/delete a drive before > > and BTRFS had to distribute unevenly cause of that. But what does it > > do on a filesystem on a single drive? I bet it would balance out > > trees? Will it resize trees with lots of unused space as well? > > The metadata trees are automatically balanced, simply by the nature > of the B-tree algorithms used. Balance won't, in general, affect them. > The only thing that a balance will achieve on a single-disk filesystem > is to reclaim unused space from allocated block groups -- so the > "total" value in your Data and Metadata entries below will go down.
But thats only for optical viewing pleasure as far as I understood you? Only if there would be not enough free space for one tree to extend then a balance would make sense? I.e. when I had a lot of metadata so that the metadata would need to extend (which seems unlikely given below figures). > > According to > > > > deepdance:~> btrfs filesystem df / > > Data: total=11.23GB, used=6.98GB > > System, DUP: total=8.00MB, used=4.00KB > > System: total=4.00MB, used=0.00 > > Metadata, DUP: total=1.86GB, used=511.35MB > > deepdance:~> btrfs filesystem show > > […] > > Label: 'debian' uuid: 2bf5b1dc-1d89-4f0d-a561-1a5551a27275 > > > > Total devices 1 FS bytes used 7.48GB > > devid 1 size 15.00GB used 14.97GB path /dev/dm-0 > > > > Btrfs Btrfs v0.19 > > > > the filesystem might have had some chances to fragment heavily, cause > > the tree sizes add up almost to the 15 GB of space available. > > > > I also remember that for some time the filesystem was nearly full > > which would explain the tree sizes. > > For metadata, the lower bound on size is 0.1% of the data size > (because checksums are computed at 4 bytes for every 4096 bytes of > data). However, data usage can be very much greater than this with > inline extents, where small files can get embedded directly in the > metadata section. This is probably more likely what explains the tree > sizes. > > I understand (although I've not done the analysis myself) that the > maximum "wasted" space in btrfs's B-tree implementation is 50%. To the > best of my knowledge, there's no compaction process for btrfs's trees > available -- nor, in general, should you need one, as a fully- > compacted tree would only have to be rearranged when more data is > added to it, thus slowing the system down after compaction. If I understand this correctly this means I can skip the balance step completely. I might still be doing the balance for that optical viewing pleasure ;). Thanks, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 -- 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
