From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 8 00:13:43 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6D6EF1065673 for ; Fri, 8 Apr 2011 00:13:43 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta05.emeryville.ca.mail.comcast.net (qmta05.emeryville.ca.mail.comcast.net [76.96.30.48]) by mx1.freebsd.org (Postfix) with ESMTP id 545E68FC14 for ; Fri, 8 Apr 2011 00:13:43 +0000 (UTC) Received: from omta14.emeryville.ca.mail.comcast.net ([76.96.30.60]) by qmta05.emeryville.ca.mail.comcast.net with comcast id Unmr1g0041HpZEsA5o0Ykn; Fri, 08 Apr 2011 00:00:32 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta14.emeryville.ca.mail.comcast.net with comcast id Uo0R1g00s1t3BNj8ao0S19; Fri, 08 Apr 2011 00:00:31 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 7AEEB9B422; Thu, 7 Apr 2011 17:00:25 -0700 (PDT) Date: Thu, 7 Apr 2011 17:00:25 -0700 From: Jeremy Chadwick To: Garrett Cooper Message-ID: <20110408000025.GA16252@icarus.home.lan> References: <4D9DF375.4080506@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Mailman-Approved-At: Fri, 08 Apr 2011 01:44:59 +0000 Cc: freebsd-fs@freebsd.org, freebsd-scsi@freebsd.org, Andriy Gapon , FreeBSD Hackers Subject: Re: retry mounting with ro when rw fails X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 00:13:43 -0000 On Thu, Apr 07, 2011 at 01:20:53PM -0700, Garrett Cooper wrote: > On Thu, Apr 7, 2011 at 10:25 AM, Andriy Gapon 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@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP 4BD6C0CB |