From owner-freebsd-fs@FreeBSD.ORG Fri Apr 8 11:45:40 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 5238B106566B; Fri, 8 Apr 2011 11:45:40 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 63A218FC1B; Fri, 8 Apr 2011 11:45:38 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id OAA05250; Fri, 08 Apr 2011 14:45:32 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4D9EF55C.5070300@FreeBSD.org> Date: Fri, 08 Apr 2011 14:45:32 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.15) Gecko/20110309 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Jeremy Chadwick References: <4D9DF375.4080506@FreeBSD.org> <20110408000025.GA16252@icarus.home.lan> In-Reply-To: <20110408000025.GA16252@icarus.home.lan> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 11:45:40 -0000 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 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