Linux Btrfs filesystem development
 help / color / mirror / Atom feed
From: Qu Wenruo <quwenruo.btrfs@gmx.com>
To: Martin Raiber <martin@urbackup.org>,
	"linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>,
	Josef Bacik <josef@toxicpanda.com>,
	Nikolay Borisov <nborisov@suse.com>
Subject: Re: ENOSPC in btrfs_drop_snapshot with 5.4.21
Date: Tue, 10 Mar 2020 10:18:33 +0800	[thread overview]
Message-ID: <fd1e84e2-c360-8089-3ac3-eed2cf73ec2a@gmx.com> (raw)
In-Reply-To: <01020170c22e02f3-0fac99b3-1cb9-4d17-88e8-4d6bab41d934-000000@eu-west-1.amazonses.com>



On 2020/3/10 上午10:02, Martin Raiber wrote:
> On 10.03.2020 02:41 Qu Wenruo wrote:
>>
>> On 2020/3/10 上午8:05, Martin Raiber wrote:
>>> Hi,
>>>
>>> I get a enospc to remount-ro with 5.4.21. Details:
>> Sorry, the attached dmesg doesn't contain the transaction abort message.
>>
>> It only has the flooded ENOSPC from enospc_debug option.
>
> This isn't it?
>
> [76641.627535] BTRFS: error (device dm-0) in btrfs_drop_snapshot:5419:
> errno=-28 No space left
> [76641.627549] BTRFS info (device dm-0): forced readonly
> [...]

Sorry, forgot it's not calling btrfs_abort_transaction() but
btrfs_handle_fs_error(), thus no backtrace.

Then it's too many pinned bytes from dropped snapshot caused the problem.

And since we're holding one transaction without ending it, it prevents
ticketed space system to flush and free space.

It looks like the check in should_end_transaction() is not good enough.

Maybe Josef and Nikolay could have some better ideas on this?

Thanks,
Qu
>
>>
>> Thanks,
>> Qu
>>> Linux 5.4.21 #1 SMP Fri Feb 21 03:20:26 CET 2020 x86_64 GNU/Linux
>>>
>>> btrfs fi usage /media/btrfs (after remount-ro)
>>> Overall:
>>>     Device size:                 511.99GiB
>>>     Device allocated:            511.99GiB
>>>     Device unallocated:              0.00B
>>>     Device missing:                  0.00B
>>>     Used:                        443.68GiB
>>>     Free (estimated):             54.94GiB      (min: 54.94GiB)
>>>     Data ratio:                       1.00
>>>     Metadata ratio:                   1.00
>>>     Global reserve:              512.00MiB      (used: 0.00B)
>>>
>>> Data,single: Size:490.98GiB, Used:436.04GiB (88.81%)
>>>    /dev/mapper/LUKS-RC-cd46b6b4909845918eaa285c532476dc  490.98GiB
>>>
>>> Metadata,single: Size:21.01GiB, Used:7.65GiB (36.40%)
>>>    /dev/mapper/LUKS-RC-cd46b6b4909845918eaa285c532476dc   21.01GiB
>>>
>>> System,single: Size:4.00MiB, Used:80.00KiB (1.95%)
>>>    /dev/mapper/LUKS-RC-cd46b6b4909845918eaa285c532476dc    4.00MiB
>>>
>>> Unallocated:
>>>    /dev/mapper/LUKS-RC-cd46b6b4909845918eaa285c532476dc      0.00B
>>>
>>> Mount options:
>>> /dev/mapper/LUKS-RC-cd46b6b4909845918eaa285c532476dc on /media/btrfs
>>> type btrfs
>>> (ro,noatime,compress-force=zstd:3,nossd,space_cache=v2,enospc_debug,skip_balance,metadata_ratio=8,subvolid=5,subvol=/)
>>>
>>> btrfs fi df /media/btrfs
>>> Data, single: total=490.98GiB, used=436.04GiB
>>> System, single: total=4.00MiB, used=80.00KiB
>>> Metadata, single: total=21.01GiB, used=7.65GiB
>>> GlobalReserve, single: total=512.00MiB, used=0.00B
>>>
>>> dmesg attached.
>>>
>

  reply	other threads:[~2020-03-10  2:18 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-10  0:05 ENOSPC in btrfs_drop_snapshot with 5.4.21 Martin Raiber
2020-03-10  1:41 ` Qu Wenruo
2020-03-10  2:02   ` Martin Raiber
2020-03-10  2:18     ` Qu Wenruo [this message]
2020-03-10  8:54 ` Nikolay Borisov
2020-03-10 12:29   ` Martin Raiber

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=fd1e84e2-c360-8089-3ac3-eed2cf73ec2a@gmx.com \
    --to=quwenruo.btrfs@gmx.com \
    --cc=josef@toxicpanda.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=martin@urbackup.org \
    --cc=nborisov@suse.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox