>So the most you would need
>> to wait for in going into the hard "read only" state I defined is for
any
>> page I/O to complete. And for the "no new writes" state, you just write
>> protect all the pages (and any new ones that fault in too).
>
>It's not that simple. At the very least you need an equivalent of msync()
>on each of these mappings before you can do anything of that kind.
I agree. An ordinary remount shouldn't immediately go into hard readonly
state. It should spend some time in no-new-writes state, during which it
flushes buffered writes, and I include in that dirty VM mapped pages, and
closes the filesystem.
My most basic point underlying all this, though, is that it should _not_
wait for all the files open for write to close (or fail because because
they haven't).
I thought there were also emergency cases where the filesystem driver
didn't want any more writing going on for fear of causing more damage.
That's why I mentioned the case where you might want to go straight to hard
readonly state.
>BTW, for real fun think of the situation when you have one of the swap
>components in a regular file on your filesystem. Do you seriously want
>do_remount() to do automagical swapoff(2) on relevant swap components?
There are all kinds of ways I can shoot myself in the foot by making a
mount readonly that I really want to be writing through. Is this one
special?
>IMO it's a userland job.
Sounds right to me. We weren't going to talk about implementation yet,
though. For starters, it would just be nice to agree what MS_RDONLY means
(and perhaps a few other similar flags).
-
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/
This archive was generated by hypermail 2b29 : Fri Sep 07 2001 - 21:00:29 EST