On Mon, Oct 29, 2018 at 6:46 PM Hugo Mills <hugo@xxxxxxxxxxxxx> wrote: > > On Mon, Oct 29, 2018 at 05:57:10PM -0400, 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. > > Opinions are divided. I find it almost impossible to read, and > always use btrfs fi df and btrfs fi show together. I find the tabular output via -T makes btrfs file usage much easier to read, and it's now the only command I use to look at it space usage on btrfs. > > There's short tutorials of how to read the output in both cases in > the FAQ, which is where I start out by directing people in this > instance. > > Hugo. > > > 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". As the output of the Usage > > command and df command clearly show, you have almost 400GiB space available. > > > > Note that the btrfs commands are clearly and explicitly displaying > > values in Binary units, (Mi, and Gi prefix, respectively). If you want > > df command to match, use -h instead of -H (see man df) > > > > An observation: > > > > 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. You can improve this by running a balance. > > > > Something like: > > btrfs balance start -dusage=55 > > > > You do *not* want to end up with all your space allocated to Data, but > > not actually used by data. Bad things can happen if you run out of > > Unallocated space for more metadata. (not catastrophic, but awkward and > > unexpected downtime that can be a little tricky to sort out.) > > > > > > > begin:vcard > > fn:Remi Gauvin > > n:Gauvin;Remi > > org:Georgian Infotech > > adr:;;3-51 Sykes St. N.;Meaford;ON;N4L 1X3;Canada > > email;internet:remi@xxxxxxxxxxxxxx > > tel;work:226-256-1545 > > version:2.1 > > end:vcard > > > > > -- > Hugo Mills | Great oxymorons of the world, no. 8: > hugo@... carfax.org.uk | The Latest In Proven Technology > http://carfax.org.uk/ | > PGP: E2AB1DE4 |
