Re: [RFD] readonly/read-write semantics

[Bryan Henderson]

>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).