retry mounting with ro when rw fails

[Andrew Duane]

I had been letting this discussion settle a little bit before jumping in, but we've done some work in this area for a few of our platforms. The work was rather ham-fisted, but I've been looking for a way to try to get it cleaned up and back to FreeBSD.

Basically, we have a way of detecting that our disk is physically write-protected, a pretty common scenario. Given that, I made some surgical changes to the mount path to prevent read-write mounts of the disk at all. You can't allow that, because even attempts to update the superblock or timestamp will fail and leave buffers outstanding. Over time, this eventually panics the system. My implementation simply drops the read-write flag and mounts the FS readonly, rather than return a failure (which stopped the startup RC scripts).

What I was hoping to do was design a better mechanism for passing that R/O detection from the device to the filesystem code. Our implementation uses a platform sysctl that checks the incoming device name against some hardware or software settings. Ick. I don't know enough about device/GEOM calls to do it better though.

 ...................................
Andrew Duane
Juniper Networks
o   +1 978 589 0551
m  +1 603-770-7088
aduane at juniper.net

 


-----Original Message-----
From: owner-freebsd-hackers at freebsd.org [mailto:owner-freebsd-hackers at freebsd.org] On Behalf Of Bruce Evans
Sent: Friday, April 08, 2011 8:20 AM
To: Andriy Gapon
Cc: Garrett Cooper; freebsd-fs at freebsd.org; Jeremy Chadwick; FreeBSD Hackers
Subject: Re: retry mounting with ro when rw fails

On Fri, 8 Apr 2011, Andriy Gapon wrote:

> on 08/04/2011 03:00 Jeremy Chadwick said the following:
>> On Thu, Apr 07, 2011 at 01:20:53PM -0700, Garrett Cooper wrote:
>>>     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.

But the default behaviour is backwards, especially for read-mostly
removable media.  The default should be ro, possibly with an automagic
upgrade to rw iff the media really needs to be written too.  Writing
timestamps for file system and inode access times doesn't count as
"really needs to be written to".

I think I prefer requiring an explicit upgrade to rw.  rw implies
writing access times unless you also use noatime, and I wouldn't want
noatime to be set automagically depending on whether rw is set explicitly,
so I would want noatime to be set explicitly, and once you do that
then you can easily set rw or ro at the same time.  A new rm (read mostly)
or "rwa" (read or write automagically) flag could give automatic upgrade
from ro to rw.  I'd also like automatic downgrade to ro after a file
system has not been written to for some time (this would avoid fscks
in most cases for read-mostly file systems.  The ro flag should be
per-cylinder-group in ffs so that on big disks, most parts are read-only
most of the time and don't need to be checked).

Bruce
_______________________________________________
freebsd-hackers at freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"