[arch-general] Btrfs blues - lack of space

[Savyasachee Jha]

On Aug 31, 2014 1:54 AM, "Jakub Klinkovský" <j.l.k at gmx.com> wrote:
>
> 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.

Thank you for all the help. In the end, I decided to get rid of about 50G
of files I didn't need (transferred them to an NTFS disk, where I saw the
size), and that increased the amount of free space I had, paradoxically, by
more than 60 gigs. I then defragmented the system and ran xdiskusage after
that. The /home/(permission denied) bit had shrunk from 48 gigs to 30 gigs.
I'm running the balance command as I type this mail to see if I manage to
free up any more space.

Again, another weird thing is that the btrfs filesystem df /home showed 398
gigs to space in home before all this, and now it shows 402 gigs. Something
is definitely up. I'll probably open up their IRC channel and talk if
someone knowledgeable happens to be online.

@Jakub Klinkovsky - In my case, du showed a lower value than btrfs fi df
/home.

Thanks,
Savya