[arch-general] Btrfs blues - lack of space

Temlin Olivér temlin at gmail.com
Sat Aug 30 15:58:06 EDT 2014


> Whenever I start my laptop up, /home takes ~17-19 seconds to mount
You can always use x-systemd.automount in fstab, which delays the mount to
the first access (ie. non-root login), or mask home.mount to be
non-blocking (oneshot), so it runs parallel with the login manager and
password input.
Slow mount times are usually caused by large log trees and fragmented
metadata. Try the autodefrag mount option and btrfs fi defrag -clzo -t 2M
-r /home (defragment files over 2M in size, recompress with lzo,
recursively), btrfs balance start /home (and wait for btrfs-endio-wri to
calm down or check with balance status, this takes some time)
If those don't help enough, try checking (but not repairing) the device
with btrfsck, and, if it's clean, clear the logs with btrfs-zero-image
after backing up the metadata with btrfs-image (consult the btrfs mailing
list or IRC first, I am not an expert in this).

> Running df -h on my system, I get:
> /dev/sda5         422G   364G   53G   88%        /home
Please use btrfs filesystem df (fi df for short), as it will show you both
the data and metadata allocation with better reflection on actual free data
space.

Point is, the allocation on B* trees can only be measured by a full tree
traversal (as your du try shows the true data usage, but misses
fragmentation), but btrfs usage is even more complicated. Authors suggest
that a device never be filled over 75% to avoid metadata fragmentation, but
by having larger files this can truly be about 95%.

Sorry for the long text, but I belive this helps in better understanding.

--Oliver Temlin


More information about the arch-general mailing list