[arch-general] Btrfs blues - lack of space

[Jakub Klinkovský]

On 30.08.14 at 21:58, Temlin Olivér wrote:
> > 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

Also note that `du` does not account for Copy-on-Write, so it could actually
show higher value than what `btrfs fi df` reports.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://mailman.archlinux.org/pipermail/arch-general/attachments/20140830/b81979a2/attachment-0001.asc>