From: Daniel Linjama <daniel@dev.linjama.com>
To: Qu Wenruo <quwenruo.btrfs@gmx.com>
Cc: linux-btrfs@vger.kernel.org, David Sterba <dsterba@suse.com>,
Chris Mason <mason@kernel.org>,
linux-kernel@vger.kernel.org,
Daniel Linjama <daniel@dev.linjama.com>
Subject: Re: [PATCH] btrfs: don't force the filesystem read-only on EDQUOT/ENOSPC verity rollback
Date: Tue, 15 Sep 2026 09:07:47 +0300 [thread overview]
Message-ID: <20260915060747.315938-1-daniel@dev.linjama.com> (raw)
In-Reply-To: <af99a1d5-25b0-4e39-9f66-a2dd8e1425c5@gmx.com>
On 2026/9/14 18:45, Qu Wenruo wrote:
> On 2026/9/14 16:02, Qu Wenruo wrote:
>> Please also submit a fstests case for it.
Sent to fstests as btrfs/354 (qgroup limit) and btrfs/355 (full
filesystem):
https://lore.kernel.org/fstests/20260915053815.307674-1-daniel@dev.linjama.com/
>> EDQUOT is fine, but I'm not sure if ENOSPC is really recoverable.
>>
>> Even if we ignore ENOSPC for now, we may have really exhausted the
>> metadata, and the next transaction may be aborted anyway.
>
> Sashiko also mentioned even if we ignored EDQUOT for now, the next mount
> we still fallback to call btrfs_drop_verity_items() on the inode cleanup.
>
> And it will return -EDQUOT again, so the inode will not be cleanred up.
>
> Considering we're only delete items, I think the better solution would
> be calling btrfs_start_transaction_fallback_global_rsv(), which will not
> enforce qgroup, thus should not return -EDQUOT in the first place.
You are both right. With v1 the next mount fails the orphan cleanup with
-EDQUOT again, every lookup of the subvolume fails, and mounting it with
-o subvol fails too, so the subvolume is unreachable as long as the limit
is in place.
v2 does what you suggest: btrfs_start_transaction_fallback_global_rsv()
in drop_verity_items(), for the second transaction in rollback_verity()
and for the orphan item deletion in btrfs_orphan_cleanup(). All three are
needed, the reservations of the dropped items are only released at
commit, so the following transactions hit the limit as well.
https://lore.kernel.org/linux-btrfs/20260915055109.311839-1-daniel@dev.linjama.com/
>> I believe your test case is only utilizing qgroup limit, or did you hit
>> a case where btrfs_drop_verity_items() returns -ENOSPC and the fs still
>> works fine?
Yes, on a full mixed block group filesystem the rollback fails with
-ENOSPC the same way. Without the fix the orphan cleanup then fails the
next read-write mount (open_ctree failed: -ENOSPC), and the filesystem
can only be mounted read-only after that. With v2 the mount succeeds and
the leftover items are dropped. btrfs/355 covers this.
Thanks,
Daniel
prev parent reply other threads:[~2026-09-15 6:08 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-14 6:24 [PATCH] btrfs: don't force the filesystem read-only on EDQUOT/ENOSPC verity rollback Daniel Linjama
2026-09-14 6:32 ` Qu Wenruo
2026-09-14 9:15 ` Qu Wenruo
2026-09-15 6:07 ` Daniel Linjama [this message]
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=20260915060747.315938-1-daniel@dev.linjama.com \
--to=daniel@dev.linjama.com \
--cc=dsterba@suse.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mason@kernel.org \
--cc=quwenruo.btrfs@gmx.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 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.