Re: speeding up slow btrfs filesystem

[Hugo Mills <hugo@carfax.org.uk>]

[-- Attachment #1: Type: text/plain, Size: 2765 bytes --]

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.

> 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.

   Hugo.

-- 
=== Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk ===
  PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
  --- I'll take your bet, but make it ten thousand francs. I'm only ---  
                       a _poor_ corrupt official.                        

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 190 bytes --]