From owner-freebsd-fs Sun Mar 5 11:12:45 2000 Delivered-To: freebsd-fs@freebsd.org Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by hub.freebsd.org (Postfix) with ESMTP id A437537BACF; Sun, 5 Mar 2000 11:12:36 -0800 (PST) (envelope-from ezk@shekel.mcl.cs.columbia.edu) Received: from shekel.mcl.cs.columbia.edu (shekel.mcl.cs.columbia.edu [128.59.18.15]) by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id OAA04279; Sun, 5 Mar 2000 14:12:31 -0500 (EST) Received: (from ezk@localhost) by shekel.mcl.cs.columbia.edu (8.9.1/8.9.1) id OAA01726; Sun, 5 Mar 2000 14:12:30 -0500 (EST) Date: Sun, 5 Mar 2000 14:12:30 -0500 (EST) Message-Id: <200003051912.OAA01726@shekel.mcl.cs.columbia.edu> From: Erez Zadok To: Kirk McKusick Cc: Alfred Perlstein , Terry Lambert , fs@FreeBSD.ORG, jkh@FreeBSD.ORG, Bruce Evans Subject: Re: changing mount options still can cause damage? In-reply-to: Your message of "Sat, 04 Mar 2000 11:34:00 PST." <200003041934.LAA16343@flamingo.McKusick.COM> Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <200003041934.LAA16343@flamingo.McKusick.COM>, Kirk McKusick writes: [...] > just as it would for a file open for writing). This seems > a slightly odd semantic for a file open for reading, so I > have not done it. Does anyone have any views on whether the > filesystem should be changed in this way on forcible > downgrades? > > Kirk Traditionally Unix file systems had all kind of odd semantics, but were considered reliable and stable. So *if* I had to choose b/t adding some odd semantics and keeping the f/s clean, I'd go for cleanliness. If, however, there is no clear winning option, then the next best thing would be to do one of the following: (1) add a new mount flag that can select among the choices. This option could be added to the mount(2) when it's doing a remount. We can select some default behavior for the flag, and let users turn it off if they want. (2) print some console message from there kernel upon remount, warning of any known open+unlinked files. BTW, can one remount read-only a f/s that's already remounted read-only? One (true hack) might be to keep the current remount semantics the same, but change them upon a second read-only remount. Erez. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message