Messages in this thread | | | Date | Sat, 5 Nov 2005 19:01:30 +0000 | From | Al Viro <> | Subject | Re: PATCH: fix-readonly-policy-use-and-floppy-ro-rw-status |
| |
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/
| |