svn commit: r299371 - in head: sbin/camcontrol sys/cam sys/cam/scsi

[Edward Tomasz Napierala]

On 0510T1020, Alan Somers wrote:
> On Tue, May 10, 2016 at 9:46 AM, Edward Tomasz Napierala <trasz at 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.  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.

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).