Re: "No space left on device"

[Hugo Mills <hugo@carfax.org.uk>]

[-- Attachment #1: Type: text/plain, Size: 2908 bytes --]

On Thu, Nov 14, 2013 at 07:54:21PM +0000, Leonidas Spyropoulos wrote:
> Hello,
> 
> I've been following this list for years and I see during various situations
> this message coming up. Some times it's a genuine problem that there is
> actually not enough space. In other cases it's some by-product of something
> else. I have seen this error personality on a broken system ( which I never
> figured out what had happened).
> I know this is still experimental but I just want to make sure my
> expectations are not really out on sync with the others.
> 
> As an end user when I see an error like this the first thing I will do is
> check the space (using 'df' command) [1]. If I see more that 7% I usually
> think it's OK, (depends on the size of partition as well).

   The problem is that there's two kinds of space (data and metadata),
and either could run out. The FS won't, currently, attempt to
reallocate between one and the other -- hence the recommendation for a
filtered balance to fix it (one of the side-effects of a balance is to
be able to free up unused or little-used chunks of allocation).

> - Is this unreasonable in btrfs filesystem? Is there a formula to calculate
> how much space btrfs _might_ need?

   Not really. I'd expect to need something in the range 250-1500 GiB
of headroom, depending on the size of the filesystem (and on the size
of the metadata).

> - It's probably not your job but can df reports correct sizes for btrfs?
> I've seen some threads on trying to show the actual space occupied by data
> and/or metadata with btrfs command. Can we expect this someone to be
> incorporated into df command?

   Sadly, no. The POSIX API for df doesn't contain enough information
to give an accurate representation of the space on the FS.

> - In cases that btrfs reports this error but there's something else that's
> causing it, can we expect better error handling from btrfs so the end user
> is pointed to the correct direction?

   Again, we're constrained by the POSIX API here -- we only have
ENOSPC to represent the error condition. I suspect the best we could
do (possibly) is print something in dmesg, where users don't tend to
look anyway.

   There's a future project on the books to make the FS attempt to
recover unused or little-used chunks, which should reduce the odds of
the ENOSPC showing up in an "unexpected" way (i.e. running out of
metadata).

   Hugo.

> [1]: one could argue that an end user should use the btrfs commands instead
> but let's leave that for now.
> 
> Apologies if these have already been answered or are already on roadmap.
> 
> Thanks in advanced, your comments are appreciated.
> 
> Kind regards,
> Leonidas
> 

-- 
=== Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk ===
  PGP key: 65E74AC0 from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
                 --- emacs: Eats Memory and Crashes. ---                 

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 828 bytes --]