retry mounting with ro when rw fails

[Jeremy Chadwick]

On Thu, Apr 07, 2011 at 01:20:53PM -0700, Garrett Cooper wrote:
> On Thu, Apr 7, 2011 at 10:25 AM, Andriy Gapon <avg at freebsd.org> wrote:
> >
> > [sorry for double post, it should have been "hackers" not "hardware"]
> >
> > Guys,
> > could you please review and comment on the following patch?
> > http://people.freebsd.org/~avg/mount-retry-ro.diff
> > Thank you!
> >
> > The patch consists of two parts.
> >
> > The first part is in CAM/SCSI to make sure that ENODEV is consistently returned to
> > signal that an operation is not supported by a device (in accordance to intro(2))
> > and specifically to return ENODEV on write attempt to a read-only or
> > write-protected media. ?Making this change in SCSI should cover real SCSI devices,
> > as well as ATAPI through ahci/siis/atapicam or similar, plus majority (all?) of
> > USB Mass Storage devices.
> >
> > The second part is in vfs_mount code. ?The idea is to re-try a mount call if we
> > get the ENODEV error, and mounting was not already in read-only mode, and there
> > was no explicit rw or noro option; the second try is changed to ro.
> >
> > I did only basic testing with an SD card in write-protected mode and a USB
> > card-reader. ?Since I am not very familiar with vfs_mount code I might have missed
> > some important details.
> 
>     As a generic question / observation, maybe we should just
> implement 'errors=remount-ro' (or a reasonable facsimile) like Linux
> has in our mount(8) command? Doesn't look like NetBSD, OpenBSD, or
> [Open]Solaris sported similar functionality.

I was going to recommend exactly this.  :-)

I like the idea of Andriy's patch, but would feel more comfortable if it
were only used if a mount option was specified (-o errors=remount-ro").
Why:

Are there any conditions where ENODEV is returned to the underlying vfs
layer for things like unexpected hardware issues?  I would imagine the
latter would be ENXIO, but I'm not certain.  An example situation:

1. User inserts USB flash drive/etc.
2. User tries to mount disk R/W manually
3. Weird/bizarre hardware issue happens mid-mount (drive falling off
   the bus, or maybe even the user yanking the drive right in the
   middle) -- could this ever return ENODEV?
4. Kernel attempts re-mount, which also fails, or possibly panics
   due to some underlying condition which nobody predicted
5. User mails mailing list

If I'm worrying over nothing, then perfect.  :-)  My other concern is
whether or not this mechanism change could caused some sort of "infinite
loop" within devd(8)/devctl(4) where the daemon gets very confused as to
what's going on or some automated commands get run when they shouldn't.

-- 
| Jeremy Chadwick                                   jdc at parodius.com |
| Parodius Networking                       http://www.parodius.com/ |
| UNIX Systems Administrator                  Mountain View, CA, USA |
| Making life hard for others since 1977.               PGP 4BD6C0CB |