From owner-freebsd-current@FreeBSD.ORG Fri Apr 8 05:13:14 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 77AD816A4CE; Fri, 8 Apr 2005 05:13:14 +0000 (GMT) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4830843D48; Fri, 8 Apr 2005 05:13:14 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id 40E8872DDD; Thu, 7 Apr 2005 22:13:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id 3C27B72DD9; Thu, 7 Apr 2005 22:13:14 -0700 (PDT) Date: Thu, 7 Apr 2005 22:13:14 -0700 (PDT) From: Doug White To: Kevin Oberman In-Reply-To: <20050406163303.3AD345D08@ptavv.es.net> Message-ID: <20050407221215.U57391@carver.gumbysoft.com> References: <20050406163303.3AD345D08@ptavv.es.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Poul-Henning Kamp cc: Robert Watson cc: current@freebsd.org Subject: Re: Panic on mount with write-locked USB media (umass) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2005 05:13:14 -0000 On Wed, 6 Apr 2005, Kevin Oberman wrote: > > Date: Tue, 5 Apr 2005 23:55:27 +0100 (BST) > > From: Robert Watson > > > > On Tue, 5 Apr 2005, Poul-Henning Kamp wrote: > > > > > In message <20050405201820.042685D07@ptavv.es.net>, "Kevin Oberman" writes: > > > > > >>> It would be useful if mount was smart enough to notice when it is > > >>> dealing with a read-only device, and try to mount such things > > >>> read-only, rather than trying to mount things read-write by default and > > >>> failing. Of course, the system shouldn't panic, either. :-) > > >> > > >> I think that is what I said. I am almost sure that this is how it used > > >> to work. I'm not sure whether the change was caused by something in > > >> msdosfs or GEOM (or somewhere else), but I sure preferred it when the RO > > >> device mounted RO. CDs still do this (thankfully). This makes me suspect > > >> msdosfs is the culprit. > > > > > > There are two ways that a filesystem correctly could handle a R/O media: > > > > > > 1. Fail with EROFS unless asked t mouned read-only > > > > > > 2. Silently downgrade th emount to read-only. > > > > > > I personally prefer the first because that way a script does not have to > > > check if it got the mount it wanted or not. > > > > In general, I agree, but this will de-POLA the following command: > > > > mount -t cd9660 /dev/acd0 /cdrom > > > > I wonder if a useful middle ground is to adopt (1) above except in the > > case of perenially read-only file systems (cd9660), in which case (2) is > > adopted? > > I hate to see such inconsistency. I don't like seeing very similar > devices behaving differently for no good reason. > > I think a better idea is a new option to allow/reject demotion to > read-only when hardware does not allow writes. POLA is slight and it > lets people do what they want to do with the issue. This would also fix mounting read-only floppies (which right now causes an undead buf when the write fails). -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org