Thread (34 messages) 34 messages, 8 authors, 2021-01-13

Re: ext4 regression in v5.9-rc2 from e7bfb5c9bb3d on ro fs with overlapped bitmaps

From: Josh Triplett <josh@joshtriplett.org>
Date: 2020-10-09 19:09:11
Also in: lkml

On Thu, Oct 08, 2020 at 07:54:09PM -0700, Darrick J. Wong wrote:
On Thu, Oct 08, 2020 at 03:38:58PM -0700, Josh Triplett wrote:
quoted
On Thu, Oct 08, 2020 at 10:54:48AM -0700, Darrick J. Wong wrote:
quoted
quoted
quoted
the head", and continued with the notion that anything other than
e2fsprogs making something to be mounted by mount(2) and handled by
fs/ext4 is being "inflicted", and if the goal didn't still seem to be
"how do we make it go away so that only e2fsprogs and the kernel ever
touch ext4". I started this thread because I'd written some userspace
code, a new version of the kernel made that userspace code stop working,
so I wanted to report that the moment I'd discovered that, along with a
potential way to address it with as little disrupton to ext4 as
possible.
Ted: I don't think it's a good idea to make SHARED_BLOCKS disable block
validity checking by default.  You could someday enable users to write
to block-sharing files by teaching ext4 how to COW, at which point you'd
need correct bitmaps and block validity to prevent accidental overwrite
of critical metadata.  At that point you'd either be stuck with the
precedent that SHARED_BLOCKS implies noblock_validity, or you'd end up
breaking Josh's images again.
That's a fair point (though I think a writable COW version of
SHARED_BLOCKS would need a different flag). It'd make more sense to key
this logic off of RO_COMPAT_READONLY or similar. But even better:
It wouldn't require a new flag -- "rocompat" features bits mean that
"it's safe to allow userspace to read files off the disk if software
doesn't recognize this feature bit".
Sure; I was more thinking that if that involved adding some data
structures to track shared blocks and the need to COW, whatever
mechanism that used might potentially need an incompat flag.
If someone /did/ add the code to write to files safely in the presence
of shared blocks, all they'd have to do to light up the functionality is
add it to the _SUPP define.  Also, it's strange that the kernel source
doesn't even know of SHARED_BLOCKS, but that's also on Ted...
It would be nice if the kernel's ext4.h header and e2fsprogs were fully
in sync, yes.

- Josh Triplett
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help