From owner-svn-src-all@freebsd.org Tue May 17 17:58:29 2016 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6B89DB3F242 for ; Tue, 17 May 2016 17:58:29 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 334CA198D for ; Tue, 17 May 2016 17:58:29 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x231.google.com with SMTP id i75so33675450ioa.3 for ; Tue, 17 May 2016 10:58:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to; bh=xTFk3c/7dGBw2vrJCe5CBU7ZyVT205rSLsEaQmjByvU=; b=IY8UJkq93MKrKXSEBV7LQnIe6QE8WfIpKOnCbni8Rnl+xWtZ9KF5HZyMWDGF4xpAss 20KA/2ZuOponImpLZ6/owLhpd7uNS7ptkQH/QF2rDrkc240ufKw8lWhk2t0aDdB9o47H 9vpWOv5Mj2ymoRIXIeFLbA7OR7R2OIV6t9/lQMORvlyyP/Njjy+DgYEbZ4C1xh4iklC9 iZ8NuIrSMLio/ittQ5MeE5EoggNdq6nvBAJqCtw2aHnHjZ8fvKo8CvAnA3r/qtIRfheD W/QyyaCIMLbIbbj/n4vJi87DPQGNdtshHDrB77WMuzKG0Q7pv4bMHLK3b682oVNmEgiy BwmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to; bh=xTFk3c/7dGBw2vrJCe5CBU7ZyVT205rSLsEaQmjByvU=; b=F7j+nfOYUh5usCjz3fTU9RZVQqv+qQJghAIAY50swb3vRv6aLzWcPqmZqymNvS8+O9 lwFsKCdVdHm0gyPIK2A/ElJNjFNoDtv9jTZaEDxD5dgChGQ0H9YS4Vm9LrSwgTjDXpNh geuNgLYJzCYatZEbfBl4HyF2jwA1KD1KPm4b+ucfzcquJ+saknI/IvG9pM8xDcQAz3Qm nG/XsWMJUxodXbQdf007EORBdykE7THl6syLsFtvm5/KU/CfD5d1vDA9RAYRbn1nf3K9 s973ivN5dNZhVo5ScP3CdPkY413kSPlkDnYVIDIJklB6kRgmjrCszVlLFfLiOMMlHP5K d3vg== X-Gm-Message-State: AOPr4FV7tJcmKsXsVn2bwTKOMk4zD5hMx6fzEOPM8r9e4mArHbgsQluJH0ZjvuhGK+F27fE3qfH4p+dEWMHYkA== MIME-Version: 1.0 X-Received: by 10.107.40.201 with SMTP id o192mr1966555ioo.183.1463507908593; Tue, 17 May 2016 10:58:28 -0700 (PDT) Sender: wlosh@bsdimp.com Received: by 10.79.75.68 with HTTP; Tue, 17 May 2016 10:58:28 -0700 (PDT) X-Originating-IP: [50.253.99.174] In-Reply-To: <20160510173351.GA4176@brick> References: <201605101546.u4AFkX0w073701@repo.freebsd.org> <20160510173351.GA4176@brick> Date: Tue, 17 May 2016 11:58:28 -0600 X-Google-Sender-Auth: iE4jpgxp4oUISRv4v-nU9mN6RaE Message-ID: Subject: Re: svn commit: r299371 - in head: sbin/camcontrol sys/cam sys/cam/scsi From: Warner Losh To: Alan Somers , "src-committers@freebsd.org" , "svn-src-all@freebsd.org" , "svn-src-head@freebsd.org" , "Kenneth D. Merry" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2016 17:58:29 -0000 On Tue, May 10, 2016 at 11:33 AM, Edward Tomasz Napierala wrote: > On 0510T1020, Alan Somers wrote: > > On Tue, May 10, 2016 at 9:46 AM, Edward Tomasz Napierala < > trasz@freebsd.org> > > wrote: > > > > > Author: trasz > > > Date: Tue May 10 15:46:33 2016 > > > New Revision: 299371 > > > URL: https://svnweb.freebsd.org/changeset/base/299371 > > > > > > Log: > > > Add "camcontrol reprobe" subcommand, and implement it for da(4). > > > This makes it possible to manually force updating capacity data > > > after the disk got resized. Without it it might be neccessary to > > > reboot before FreeBSD notices updated disk size under eg VMWare. > > > > > > Discussed with: imp@ > > > MFC after: 1 month > > > Sponsored by: The FreeBSD Foundation > > > Differential Revision: https://reviews.freebsd.org/D6108 > > > > > > Modified: > > > head/sbin/camcontrol/camcontrol.8 > > > head/sbin/camcontrol/camcontrol.c > > > head/sys/cam/cam_ccb.h > > > head/sys/cam/cam_xpt.c > > > head/sys/cam/scsi/scsi_da.c > > > > > > > > > > I too have been annoyed that "camcontrol rescan" won't update capacity > > data. But could we solve the problem by simply adding logic to > "camcontrol > > rescan" instead of adding an entirely new command? Would a user ever > want > > to rescan a device without reprobing it too? > > Two reasons. First, I want to be able to pass the device name (like > 'da0') and not the CAM path (like 1:0:0) for usability reasons - it seems > easy to figure out the latter from the former, using "camcontrol devlist", > but it suddenly becomes complicated when you try to explain it in a man > page. You can look up one or the other. fwdownload uses the daX name. > Second - I don't understand the "camcontrol rescan" logic well > enough, and "camcontrol rescan all" sometimes fails for me anyway, > in a way I'm not sure how to debug. > That's a cop-out. CAM is hard, but if you aren't willing to figure itout, adding hacks that the other CAM maintainers have to cope with doesn't help. Also, to be honest I'm not sure those two are actually that related. > Rescanning is about discovering new devices on the bus. "Reprobe" > is about updating... well, mostly updating the capacity. The former > requires enumerating the bus using a mechanism built into XPT; the > latter is just notifying the periph driver (in this case da(4)) that > it needs to query the capacity and call disk_resize(4). > The two are very related. Now we have two stupid paths in CAM instead of one. and you didn't do ada like I asked. Not happy with this at all, but not asking for a back out. Warner