From owner-freebsd-fs@FreeBSD.ORG Fri Apr 8 12:48:58 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A1E3F106566B for ; Fri, 8 Apr 2011 12:48:58 +0000 (UTC) (envelope-from aduane@juniper.net) Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by mx1.freebsd.org (Postfix) with ESMTP id 3C10B8FC15 for ; Fri, 8 Apr 2011 12:48:57 +0000 (UTC) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP ID DSNKTZ8EOSNVMk/GEKtw0FArl9VC+NI3+I1Y@postini.com; Fri, 08 Apr 2011 05:48:58 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 8 Apr 2011 05:34:50 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Fri, 8 Apr 2011 08:36:35 -0400 From: Andrew Duane To: Bruce Evans , Andriy Gapon Date: Fri, 8 Apr 2011 08:36:33 -0400 Thread-Topic: retry mounting with ro when rw fails Thread-Index: Acv15/dwjMS1LW5+RZe5mMMKTZtQ9gAAMwHw Message-ID: References: <4D9DF375.4080506@FreeBSD.org> <20110408000025.GA16252@icarus.home.lan> <4D9EF55C.5070300@FreeBSD.org> <20110408214920.I1265@besplex.bde.org> In-Reply-To: <20110408214920.I1265@besplex.bde.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Garrett Cooper , "freebsd-fs@freebsd.org" , FreeBSD, Hackers Subject: RE: retry mounting with ro when rw fails X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 12:48:58 -0000 I had been letting this discussion settle a little bit before jumping in, b= ut we've done some work in this area for a few of our platforms. The work w= as rather ham-fisted, but I've been looking for a way to try to get it clea= ned up and back to FreeBSD. Basically, we have a way of detecting that our disk is physically write-pro= tected, 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 w= ill fail and leave buffers outstanding. Over time, this eventually panics t= he system. My implementation simply drops the read-write flag and mounts th= e FS readonly, rather than return a failure (which stopped the startup RC s= cripts). 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. =A0................................... Andrew Duane Juniper Networks o=A0=A0=A0+1 978 589 0551 m=A0 +1 603-770-7088 aduane@juniper.net =A0 -----Original Message----- From: owner-freebsd-hackers@freebsd.org [mailto:owner-freebsd-hackers@freeb= sd.org] On Behalf Of Bruce Evans Sent: Friday, April 08, 2011 8:20 AM To: Andriy Gapon Cc: Garrett Cooper; freebsd-fs@freebsd.org; Jeremy Chadwick; FreeBSD Hacker= s 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=3Dremount-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=3Dremount-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 th= en > explicitly -o ro, you "just want" to get that media mounted then the defa= ult > 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@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"