[HOWTO] BTRFS metadata block group profile "dup" vs "single"

asked 2017-05-29 22:36:19 +0200

DrYak gravatar image

updated 2019-07-18 13:13:15 +0200

Tip about profiles of metadata block groups :

By default the BTRFS partition on the Jolla 1 phone uses "dup" profile for the metadata block groups.

i.e.: BTRFS will keep 2 copies of each metadata block group.

According to the mkfs.btrfs manpage, this isn't recommended on SSD anymore.

(e.g.: the flash translation layer / wear-leveling of flash media will very likely group the writes together, which will cause both dup copies to end up on the same erase-block. If the flash goes bust, both copies will very likely end-up lost at the same time, negating any benefit of dup profiles on flash media, as opposed to rotational media)

I would suggest switching the pofile :

devel-su
btrfs balance start -v -f -mconvert=single /

This will reduce the amount of space allocated on metadata block groups by half, which will reduce a bit the pressure on the free-space / the partition full problems that users report.

I've personally used my smartphone (both eMMC and uSDHC card) this way for over 1 year without any problem to report (Including going through SailfishOS updates, surviving crashes, etc.)

edit retag flag offensive close delete

Comments

Any measurements, how big a difference it makes spacewise?

juiceme ( 2017-05-31 11:44:50 +0200 )edit
2

Currently, my Jolla 1 (which I've recently balanced - I do periodically run btrfs balance -v -dusage=60 -musage=80 /) has allocated 512MiB worth of block group for its metadata. (Note: metadata on smaller devices is allocated in chunks of 256MiB )

It currently uses exactly 512 MiB / 0.5 GiB on the eMMC in single mode. Had I left the dup mode, it would have used twice the amound - i.e.: 1.0 GiB.

Now, the root partition on Jolla 1 is exactly 13GiB and 764MiB. That means it could allocate up to 13 data block groups (their are always allocated in chunks of 1 GiB), and still could allocation 512 MiB of metadata. Had I use dup instead, that would only had left me 12GiB(+764MiB) of space left after the metadata and thus only 12 data block groups maximum.

If the meta data needed to allocate 1 more block groups, in the current situation, that would total 768MiB of allocation, leaving me 12 data block group possible (just a couple of MiB short of 13 data block groups). In dup mode, that would have taken 3.0 GiB on disk, and thus left me with only 10 data block groups possible.

Reducing redundancy from dup to single not only avoids useless copies (remember : the flash translation layer of the eMMC will pack them together anyway, that would completely negate their benefit), it reduces a lot the risk of hitting the dreaded "enospc" error.

DrYak ( 2017-06-03 02:54:28 +0200 )edit
1

Another possible optimisation would be to use mixed mode block groups. Where both data and metadata are stored in the same 256 MiB block groups. But BTRFS only auto-enables it for 1.0GiB devices, and it's not recommanded beyond 5.0GiB - it's not worth the performance hit.

I'm also not sure if the antiquated kernel version (3.4.108) that the qualcom chipset forces upon us is already well tested for mixed mode block groups and if it's considered stable or in "RAID5/6" state :-P (Though Jolla does backport later improvements into this kernel so some later bugs could have been fixed).

DrYak ( 2017-06-03 03:00:47 +0200 )edit