Btrfs devel - Oct 2013 - Metadata reservation

I have just moved some partitions on two Linux (Mageia 3) boxes to btrfs 
(call the boxes A and B). In both cases only a part of one physical disk 
can be allocated to btrfs.

On box A, the btrfs partition size is 419 GB and the resulting usable 
space is 418 GB with 1GB reserved by btrfs for metadata.

However, on box B, where the partition size is 388 GB, reserved metadata 
amounts to 128 GB (!), leaving just 266 GB for data.

I''ve now done box B twice. Once using btrfs-convert and once by 
reverting to ext4, and using KDE control centre to change the type of 
the partition to btrfs, restoring the data from backups. In both cases 
metadata reservation amount to 128 GB -- about 30% of the disk.

Any suggestions on (a) what the cause might be and (b) how to improve 
things?

Thanks in advance,

-- 
Mike Arnautov
mailto:mla@mipmip.org
http://mipmip.org
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs"
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On Wed, Oct 30, 2013 at 12:15:16PM +0000, Mike Arnautov
wrote:
> I have just moved some partitions on two Linux (Mageia 3) boxes to
> btrfs (call the boxes A and B). In both cases only a part of one
> physical disk can be allocated to btrfs.
> 
> On box A, the btrfs partition size is 419 GB and the resulting
> usable space is 418 GB with 1GB reserved by btrfs for metadata.
> 
> However, on box B, where the partition size is 388 GB, reserved
> metadata amounts to 128 GB (!), leaving just 266 GB for data.
> 
> I''ve now done box B twice. Once using btrfs-convert and once by
> reverting to ext4, and using KDE control centre to change the type
> of the partition to btrfs, restoring the data from backups. In both
> cases metadata reservation amount to 128 GB -- about 30% of the
> disk.
> 
> Any suggestions on (a) what the cause might be and (b) how to
> improve things?
(a) Probably a kernel somewhere in the range 3.7-3.8 (possibly 3.6).
   These kernels had a problem with excessively overenthusiastic chunk
   allocation. If that''s the case, a newer kernel should stop it
   happening again. Alternatively, you''ve got lots and lots of small
   (<3k) files, and it''s decided to inline them all.

(b) btrfs balance start -musage=5 /mountpoint should cleean up any
   little-used or empty chunk allocations, but on the kernels above,
   it''ll probably overallocate again. You may need to bump the usage
   parameter up a bit (it''s a percentage) to harvest more chunks, if
   the first run isn''t sufficient.

   If you still have the problem, then send us the output of:

btrfs fi show
btrfs fi df /mountpoint
uname -a

and we can take another look at it.

   Hugo.

-- 
=== Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk ==  PGP
key: 65E74AC0 from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
           --- All hope abandon,  Ye who press Enter here. ---