在 2025/7/15 04:32, David Sterba 写道:
On Mon, Jul 14, 2025 at 12:27:37PM +0200, Christian Brauner wrote:
[...]
The remaining concern is just should we do this by using
->freeze_super() callback, or do the f2fs' way by poking into
s_writer.frozen.
I'd prefer the later one, as that's already exposed to filesystems and we do
not need extra callback functions especially when it's not widely used.
This would be simpler. You should probably add a helper that you can
share with gfs2 to sample the state instead of raw accesses to
s_writers->frozen. I find the latter a bit ugly and error prone if we
ever change this. I'd rather have it encapsulated in the VFS layer as
best as we can.
I chose to use separate bit rather than using s_writers->frozen, which
is what Qu prefers. I disgree with that on the API level as we probably
should not do such direct check. A helper would be best, semantically
teh same as the added filesystem bit.
My biggest complain about the new ->freeze_super() callback is, it's
very confusing to have both ->freeze_super() and ->freeze_fs().
Currently only GFS2 is utilizing that, and I'm not sure if it can be
removed or not, as it's some gfs specific lock handling.
In our btrfs case, it's really just a single bit that can also be done
by checking s_writer.frozen, thus I don't think doing the extra
callbacks just for that bit is really worthy.
Talking about the extra helpers to handle the access, it's valid,
although we may have several different helpers, as each fs has different
checks.
This makes the helper almost the same to the raw access to
s_writers->frozen.
E.g. f2fs' gc and quota check if the fs is being/already frozen, thus
it's the same as the btrfs's one.
But there are other call sites checking if the freezing is fully
completed, and xfs even checks on the specific frozen stage.
So if one day we really change the s_writer->frozen stages, it will
touch quite some fs codes anyway.
Thanks,
Qu
