retry mounting with ro when rw fails

[Andriy Gapon]

on 08/04/2011 03:00 Jeremy Chadwick said the following:
> 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").

Having the option is appealing, but my main motivation was the simplicity that
comes from having that enabled by default.
That is, you absolutely want an R/W mount then use -o rw, you need R/O then
explicitly -o ro, you "just want" to get that media mounted then the default
behavior tries its best.

> 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?

It shouldn't.  If that happens then the underlying layers should be fixed.

> 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.

I can't see how that can happen.

-- 
Andriy Gapon