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.
Attachment:
pgpIZPlSss152.pgp
Description: PGP signature
