May not have existed, then, which *would* explain it. :-)
>>> Another problem was the ability to change the mount status of a
>>> partition from read-write to read-only or to unmounted,
>> See NetBSD (and presumably other BSD) "mount -o update,rdonly"
>> and/or "umount -f".
> If you re-read the original message, the problem is what to do about
> processes with open file descriptors on the partition: stop them at
> once? stop them at first file access? block them instead? kill them?
Yes, that's the most difficult part.
The NetBSD manpage doesn't say what happens if you "mount -o
update,force,rdonly" when there are writeable descriptors open onto the
filesystem, and then try to use those fds. I would assume further
attempts to write would produce errors (EROFS?), unless of course the
filesystem has been re-remounted read/write.
The manpage for umount says
-f The filesystem is forcibly unmounted. Active special devices
continue to work, but all other files return errors if further
accesses are attempted.
I haven't looked at the relevant kernel code to see what *really*
happens.
> How will you allow for such large table-walking to be compatible with
> real-time kernel response?
*What* large table-walking? All this means you have to do is have
every write check the relevant mount point to see if it's mounted
read-only, for downgrading remounts, and mark the filesystem as gone,
for forced unmounts. (I suspect this is what deadfs is for.)
>>> I intend to put free unices in competition [...]
>> Reasonable as this sounds, I think the last thing we need is yet
>> another ground on which one free-unix can be doing the "nana nana
>> boo boo" taunt at another.
> Competition is _not_ about taunting each other for pride;
I know this. I even think most of the people involved know it.
But there seem to be a few - not many, but very poisonous - who seem to
take any competition - indeed, almost any *difference* - as an
opportunity for "we're better than you" egoboo.
der Mouse
mouse@rodents.montreal.qc.ca
7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/