All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ole Langbehn <neurolabs.de@gmail.com>
To: linux-btrfs@vger.kernel.org
Subject: repeated enospc errors during balance on a filesystem with spare room - pls advise
Date: Tue, 31 Dec 2019 16:04:07 +0100	[thread overview]
Message-ID: <495cfb98-7afd-a36d-151b-d7cc58f1d352@gmail.com> (raw)


[-- Attachment #1.1: Type: text/plain, Size: 2015 bytes --]

Hi,

I have done three full balances in a row, each of them ending with an
error, telling me:

BTRFS info (device nvme1n1p1): 2 enospc errors during balance
BTRFS info (device nvme1n1p1): balance: ended with status: -28

(first balance run it was 4 enospc errors).

The filesystem has enough space to spare, though:

# btrfs fi show /
Label: none  uuid: 34ea0387-af9a-43b3-b7cc-7bdf7b37b8f1
        Total devices 1 FS bytes used 624.36GiB
        devid    1 size 931.51GiB used 627.03GiB path /dev/nvme1n1p1

# btrfs fi df /
Data, single: total=614.00GiB, used=613.72GiB
System, single: total=32.00MiB, used=112.00KiB
Metadata, single: total=13.00GiB, used=10.64GiB
GlobalReserve, single: total=512.00MiB, used=0.00B

This is after the balances, but was about the same before the balances.
Before them, data had about 50GB diff between total and used.

The volume contains subvolumes (/ and /home) and snapshots (around 20
per subvolume, 40 total, oldest 1 month old).

My questions are:

1. why do I get enospc errors on a device that has enough spare space?
2. is this bad and if yes, how can I fix it?



A little more (noteworthy) context, if you're interested:

The reason I started the first balance was that a df on the filesystem
showed 0% free space:

# df
Filesystem     1K-blocks      Used Available Use% Mounted on
/dev/nvme1n1p1 976760584 655217424 	   0 100% /
...

and a big download (chromium sources) was aborted due to "not enough
space on device".

I monitored the first balance more closely, and right after the start,
df looked normal again, showing available blocks, but during the
balance, it flip-flopped a couple of times between again showing 0
available bytes and showing the complement between actual size and used
bytes. I did not observe this behavior any more during balance 2 and 3,
but did not observe as closely.

TiA for any insights and ideas on how to proceed and a healthy start
into the new year for everyone.





[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

             reply	other threads:[~2019-12-31 15:06 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-31 15:04 Ole Langbehn [this message]
2019-12-31 15:10 ` repeated enospc errors during balance on a filesystem with spare room - pls advise Ole Langbehn
2019-12-31 22:58   ` Zygo Blaxell
2020-01-01 10:05     ` Swâmi Petaramesh
2020-01-01 23:38       ` Zygo Blaxell
2020-01-01 17:40     ` Ole Langbehn
2020-01-01  0:13 ` Qu Wenruo
2020-01-01  9:54   ` Cerem Cem ASLAN

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=495cfb98-7afd-a36d-151b-d7cc58f1d352@gmail.com \
    --to=neurolabs.de@gmail.com \
    --cc=linux-btrfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.