* >However, if I try to mount it from B read-only while A is mounting it * >read-write, it succeeds. This looks dangerous, as A writing data onto * >the disk could cause B's cache to go stale without B knowing it. Is * >it a good idea to allow read-only mounts of a dirty filesystem anyway? * >(The filesystem could be corrupted, right?) * * UFS/FFS doesn't expect anybody else to muck about on the device * while they have it open, and violating that is a bad idea, I cannot
I know that, but that's not the point here. If the filesystem is marked dirty, it could very well be corrupted. Why am I allowed to mount it (even read-only)? I use softupdates on these filesystems, and my understanding is that it is theoretically safe to mount a filesystem without fsck after a crash if it's using softupdates. But I don't see mount checking that (if it is, it should allow read-write mounts too -- mount -f is not quite the same thing is it will override the check even for non-softupdates case). * tell if it would lead to panics, but I can imagine a couple of ways * it would become quantum mechanical in such a setup. * A couple of filesystem have been designed over the years which allow * for multiple machine access, but they tend to have lousy performance * because of caching being so inefficient. One of the better * implementations cheated, they stored the stuff in an Oracle database * on a third machine, but used a filesystem interface... To clarify, we're not trying to build a distributed filesystem here. We're planning to use the disks from both machines read-only most of the time, and unmount it from one machine if the other needs to write to it. I was just wondering what kind of safety belts the OS already has, so we can decide what else we need to implement. Satoshi To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
