On Tue, Oct 30, 2018 at 10:10 AM, Ulli Horlacher <frams...@rus.uni-stuttgart.de> wrote: > > On Mon 2018-10-29 (17:57), Remi Gauvin wrote: >> On 2018-10-29 02:11 PM, Ulli Horlacher wrote: >> >> > I want to know how many free space is left and have problems in >> > interpreting the output of: >> > >> > btrfs filesystem usage >> > btrfs filesystem df >> > btrfs filesystem show >> >> In my not so humble opinion, the filesystem usage command has the >> easiest to understand output. It' lays out all the pertinent information. >> >> You can clearly see 825GiB is allocated, with 494GiB used, therefore, >> filesystem show is actually using the "Allocated" value as "Used". >> Allocated can be thought of "Reserved For". > > And what is "Device unallocated"? Not reserved?
That's a reasonable interpretation. Unallocated space is space that's not used for anything: no data, no metadata, and isn't reference by any block group. It's not a relevant number day to day, I'd say it's advanced leaning toward esoteric knowledge of Btrfs internals. At this point I'd like to see a simper output by default, and have a verbose option for advanced users, and an export option that spits out a superset of all available information in a format parsable for scripts. But I know there are other project that depend on btrfs user space output, rather than having something specifically invented for them that's easily parsed, and can be kept consistent and extendible, separate from human user consumption. Oh well! >> The disparity between 498GiB used and 823Gib is pretty high. This is >> probably the result of using an SSD with an older kernel. If your >> kernel is not very recent, (sorry, I forget where this was fixed, >> somewhere around 4.14 or 4.15), then consider mounting with the nossd >> option. > > I am running kernel 4.4 (it is a Ubuntu 16.04 system) > But /local is on a SSD. Should I really use nossd mount option?! Yes. But it's not a file system integrity suggestion, it's an optimization. > > > >> You can improve this by running a balance. >> >> Something like: >> btrfs balance start -dusage=55 > > I run balance via cron weekly (adapted > https://software.opensuse.org/package/btrfsmaintenance) With a newer kernel you can probably reduce this further depending on your workload and use case. And optionally follow it up with executing fstrim, or just enable fstrim.timer (we don't recommend using discard mount option for most use cases as it too aggressively discards very recently stale Btrfs metadata and can make recovery from crashes harder). There is a trim bug that causes FITRIM to only get applied to unallocated space on older file systems, that have been balanced such that block group logical addresses are outside the physical address space of the device which prevents the free space inside of such block groups to be passed over for FITRIM. Looks like this will be fixed in kernel 4.20/5.0 -- Chris Murphy
