Date: Sat, 16 Jan 1999 02:46:30 -0800 (PST) From: asami@FreeBSD.ORG (Satoshi Asami) To: phk@critter.freebsd.dk Cc: current@FreeBSD.ORG Subject: Re: mounting double-ended SCSI disks Message-ID: <199901161046.CAA47630@silvia.hip.berkeley.edu> In-Reply-To: <9602.916482530@critter.freebsd.dk> (message from Poul-Henning Kamp on Sat, 16 Jan 1999 11:28:50 %2B0100)
next in thread | previous in thread | raw e-mail | index | archive | help
* >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 majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199901161046.CAA47630>