From owner-freebsd-fs@FreeBSD.ORG Fri Apr 8 02:16:46 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 DBAA81065670; Fri, 8 Apr 2011 02:16:45 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 76C1A8FC0A; Fri, 8 Apr 2011 02:16:45 +0000 (UTC) Received: by pwj8 with SMTP id 8so1425939pwj.13 for ; Thu, 07 Apr 2011 19:16:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=kpT/2d4MXnsBu5MHzOKiNh1Wg0A3NsW/hoJOXYlrNoQ=; b=u73BnxZejx0aPjIJuOE2VXYFDjfY7Dl8AIFgcWQfsM8hhrbhZy3cpVEFpp5ouzNZ6e r76WL8aSf7Aou18dceFayW0xpUKF4O0uGP1QvQD/uM/j7Mpd0W5i7dgVUy/4npezERBH ldm/T/Mik9DRue+qNU4cZHhkBBfHBuOa7UjL4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=VW8Jc1rPHHqFbpFm5oeR/3x/ep0w9jBF4iAcyJzK+U+Yuegletww0Q/RXvYplNnOmm a/tdWxK7ZZNaOrgifdmnorwot7KEXzKnvDzWsGj2GzMPam9/Sp8w/9vAeBmMzcIdnTUl AoS8HSIk3IWJz95c+MhPI6mooutKPxEQvAGlc= MIME-Version: 1.0 Received: by 10.143.24.39 with SMTP id b39mr1225326wfj.341.1302229004786; Thu, 07 Apr 2011 19:16:44 -0700 (PDT) Received: by 10.68.42.3 with HTTP; Thu, 7 Apr 2011 19:16:44 -0700 (PDT) In-Reply-To: <20110408000025.GA16252@icarus.home.lan> References: <4D9DF375.4080506@FreeBSD.org> <20110408000025.GA16252@icarus.home.lan> Date: Thu, 7 Apr 2011 19:16:44 -0700 Message-ID: From: Garrett Cooper To: Jeremy Chadwick Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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-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 02:16:46 -0000 On Thu, Apr 7, 2011 at 5:00 PM, Jeremy Chadwick wrote: > 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 t= o 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 S= CSI 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 c= all 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. >> >> =A0 =A0 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. =A0:-) > > 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"). > Why: > > Are there any conditions where ENODEV is returned to the underlying vfs > layer for things like unexpected hardware issues? =A0I would imagine the > latter would be ENXIO, but I'm not certain. =A0An 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 > =A0 the bus, or maybe even the user yanking the drive right in the > =A0 middle) -- could this ever return ENODEV? > 4. Kernel attempts re-mount, which also fails, or possibly panics > =A0 due to some underlying condition which nobody predicted > 5. User mails mailing list > > If I'm worrying over nothing, then perfect. =A0:-) =A0My 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. Yeah. It seems like something else like EINVAL (just an example -- probably a bad one) would be better. Also, please be careful as returning ENODEV seems to be UFS-specific: The following errors can occur for a ufs file system mount: [ENODEV] A component of ufs_args fspec does not exist. Also, Tom Rhodes has a similar change to what I suggested on the backburner, but it hasn't been 100% fleshed out yet. Thanks, -Garrett