Re: PATCH: fix-readonly-policy-use-and-floppy-ro-rw-status

[Al Viro <viro@ftp.linux.org.uk>]

On Sat, Nov 05, 2005 at 06:51:39PM +0000, Jon Masters wrote:
> On 11/5/05, Al Viro <viro@ftp.linux.org.uk> wrote:
> > On Sat, Nov 05, 2005 at 06:40:28PM +0000, Jon Masters wrote:
> > > And as I said, the situation as it stands leads to potential data
> > > corruption but I agree with you - we need a VFS callback to handle
> > > readwrite/readonly change on remount I think. Comments?
> 
> > It's not that simple.  Filesystem side of ro/rw transitions is
> > messy as hell
> 
> Agreed.
> 
> > "VFS callback" won't be enough.
> 
> Although strangely enough other similar stuff in the remount path
> works just fine. I can already request that a filesystem gets
> remounted read-only - what's so wrong with forcing that behaviour when
> I ask for an impossible combination?

->remount_fs() certainly can refuse to go r/w - you don't need anything
new for that, just don't leave MS_RDONLY in *flags.  The real trouble
starts when fs wants to go r/o on its own, e.g. when it sees an error
bad enough to warrant that.  And that, BTW, is very likely to require
more than just one bit in ->policy - we want all IO on that device
to fail until after we actually close it during umount.  As it is,
we can get anything, including block allocations (e.g. if we have
a dirty mapping and it gets written to disk).  OTOH, we don't want
it to be the same thing as genuine hardware readonly - when buggered
fs is umounted, we are very likely to do fsck on it, after all.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/