[arch-general] Btrfs blues - lack of space
Hello, all The contents of my /etc/fstab are as follows: /dev/sda3 / btrfs rw,relatime,space_cache,autodefrag 0 0 /dev/sda1 /boot ext2 rw,relatime 0 2 /dev/sda5 /home btrfs rw,relatime,space_cache,autodefrag 0 0 Whenever I start my laptop up, /home takes ~17-19 seconds to mount, as is evidenced by this line in the output of systemd-analyze blame: 16.467s home.mount Running df -h on my system, I get: Filesystem Total Used Free Use% Mounted on /dev/sda5 422G 364G 53G 88% /home However, running du -h --summarize /home, I get: 318G /home If I use xdiskusage to see the partition, it shows 46.48G as /home/(permission denied). I tried doing this using sudo, and I still have the same problem. I have neither subvolumes nor any snapshots on this volume. Is there any way of recovering this space? Thank you, Savya -- Savyasachee Jha *"Aerodynamics is for people whodon't know how to build engines."*
On 30.08.14 at 23:09, Savyasachee Jha wrote:
Hello, all
The contents of my /etc/fstab are as follows:
/dev/sda3 / btrfs rw,relatime,space_cache,autodefrag 0 0 /dev/sda1 /boot ext2 rw,relatime 0 2 /dev/sda5 /home btrfs rw,relatime,space_cache,autodefrag 0 0
Whenever I start my laptop up, /home takes ~17-19 seconds to mount, as is evidenced by this line in the output of systemd-analyze blame:
16.467s home.mount
Running df -h on my system, I get:
Filesystem Total Used Free Use% Mounted on /dev/sda5 422G 364G 53G 88% /home
However, running du -h --summarize /home, I get:
318G /home
If I use xdiskusage to see the partition, it shows 46.48G as /home/(permission denied). I tried doing this using sudo, and I still have the same problem. I have neither subvolumes nor any snapshots on this volume.
Is there any way of recovering this space?
Thank you, Savya
-- Savyasachee Jha
*"Aerodynamics is for people whodon't know how to build engines."*
Use: $ btrfs filesystem df /home
On Sun, Aug 31, 2014 at 12:29 AM, Jakub Klinkovský <j.l.k@gmx.com> wrote:
On 30.08.14 at 23:09, Savyasachee Jha wrote:
Hello, all
The contents of my /etc/fstab are as follows:
/dev/sda3 / btrfs rw,relatime,space_cache,autodefrag 0 0 /dev/sda1 /boot ext2 rw,relatime 0 2 /dev/sda5 /home btrfs rw,relatime,space_cache,autodefrag 0 0
Whenever I start my laptop up, /home takes ~17-19 seconds to mount, as is evidenced by this line in the output of systemd-analyze blame:
16.467s home.mount
Running df -h on my system, I get:
Filesystem Total Used Free Use% Mounted on /dev/sda5 422G 364G 53G 88% /home
However, running du -h --summarize /home, I get:
318G /home
If I use xdiskusage to see the partition, it shows 46.48G as /home/(permission denied). I tried doing this using sudo, and I still have the same problem. I have neither subvolumes nor any snapshots on this volume.
Is there any way of recovering this space?
Thank you, Savya
-- Savyasachee Jha
*"Aerodynamics is for people whodon't know how to build engines."*
Use: $ btrfs filesystem df /home
I just did that, and I get: Data, single: total=396.01GiB, used=362.83GiB System, DUP: total=8.00MiB, used=48.00KiB System, single: total=4.00MiB, used=0.00 Metadata, DUP: total=3.00GiB, used=594.23MiB Metadata, single: total=8.00MiB, used=0.00 unknown, single: total=200.00MiB, used=0.00 This gives me a totally different count of total space. Why's that? -- Savyasachee Jha *"Aerodynamics is for people whodon't know how to build engines."*
On , Savyasachee Jha wrote:
I just did that, and I get:
Data, single: total=396.01GiB, used=362.83GiB System, DUP: total=8.00MiB, used=48.00KiB System, single: total=4.00MiB, used=0.00 Metadata, DUP: total=3.00GiB, used=594.23MiB Metadata, single: total=8.00MiB, used=0.00 unknown, single: total=200.00MiB, used=0.00
This gives me a totally different count of total space. Why's that?
Checkout btrfs wiki, there are some entries about free space. https://btrfs.wiki.kernel.org/index.php/FAQ#Why_are_there_so_many_ways_to_ch... P. -- There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors.
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
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.
On Aug 31, 2014 1:54 AM, "Jakub Klinkovský" <j.l.k@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
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.
As per my experience, always sync before measuring free space. - -Oliver Temlin
On Sun, Aug 31, 2014 at 1:28 AM, Temlin Olivér <temlin@gmail.com> 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
I defragged the filesystem and balanced it, before scrubbing it for good measure, and then rebooted. The problems with the long booting time disappeared (without using the systemd mount option in fstab). However, xdiskusage still shows /home/(permission denied) to be about 30 gigs. I realise that that space might be in use by the FS for some reason and trying to recover it might be beyond me. Keeping used space at below 75% does seem to help a lot. However, this is a slightly weird expectation for a mainline filesystem. If I have a 2TB external hard disk (which I'm thinking of buying in a few days), formatting it with btrfs seems an easy way to convert it to a 1.5TB without really gaining substantial benefits. I guess XFS and Ext4 really are better for this use case. I'd like to thank everyone for the help I got on this issue, especially Oliver Temlin, whose inputs managed to help me solve this neatly. I also got to learn a lot about btrfs, which is a big plus. Cheers, Savya -- Savyasachee Jha *"Aerodynamics is for people whodon't know how to build engines."*
participants (4)
-
Jakub Klinkovský
-
Paladin
-
Savyasachee Jha
-
Temlin Olivér