Date: Tue, 17 May 2016 11:58:28 -0600 From: Warner Losh <imp@bsdimp.com> To: Alan Somers <asomers@freebsd.org>, "src-committers@freebsd.org" <src-committers@freebsd.org>, "svn-src-all@freebsd.org" <svn-src-all@freebsd.org>, "svn-src-head@freebsd.org" <svn-src-head@freebsd.org>, "Kenneth D. Merry" <ken@freebsd.org> Subject: Re: svn commit: r299371 - in head: sbin/camcontrol sys/cam sys/cam/scsi Message-ID: <CANCZdfqBZTFNP8uEuUyBs%2B4CQuvHq2efsN9aMmA046iQ7MhZdg@mail.gmail.com> In-Reply-To: <20160510173351.GA4176@brick> References: <201605101546.u4AFkX0w073701@repo.freebsd.org> <CAOtMX2jJTKMM=kjJy0uUnkK93cDs_N5c5ohYnLq3CAd-fOYW2A@mail.gmail.com> <20160510173351.GA4176@brick>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, May 10, 2016 at 11:33 AM, Edward Tomasz Napierala <trasz@freebsd.org > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfqBZTFNP8uEuUyBs%2B4CQuvHq2efsN9aMmA046iQ7MhZdg>