On Sat, Nov 05, 2005 at 06:51:39PM +0000, Jon Masters wrote:
> On 11/5/05, Al Viro <[email protected]> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
