Messages in this thread |  | | Subject | Re: [RFD] readonly/read-write semantics | From | "Bryan Henderson" <> | Date | Tue, 4 Sep 2001 19:34:17 -0700 |
| |
>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/
|  |