Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 7 Apr 2005 22:13:14 -0700 (PDT)
From:      Doug White <dwhite@gumbysoft.com>
To:        Kevin Oberman <oberman@es.net>
Cc:        current@freebsd.org
Subject:   Re: Panic on mount with write-locked USB media (umass) 
Message-ID:  <20050407221215.U57391@carver.gumbysoft.com>
In-Reply-To: <20050406163303.3AD345D08@ptavv.es.net>
References:  <20050406163303.3AD345D08@ptavv.es.net>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 6 Apr 2005, Kevin Oberman wrote:

> > Date: Tue, 5 Apr 2005 23:55:27 +0100 (BST)
> > From: Robert Watson <rwatson@FreeBSD.org>
> >
> > 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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050407221215.U57391>