From owner-svn-src-all@freebsd.org Wed May 18 09:56:44 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 38D2DB3E2C8; Wed, 18 May 2016 09:56:44 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: from mail-wm0-x244.google.com (mail-wm0-x244.google.com [IPv6:2a00:1450:400c:c09::244]) (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 BDC251B71; Wed, 18 May 2016 09:56:43 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: by mail-wm0-x244.google.com with SMTP id r12so11444034wme.0; Wed, 18 May 2016 02:56:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:mail-followup-to :references:mime-version:content-disposition:in-reply-to:user-agent; bh=n+bKjHvNfBsAR52qQoWih8gdjH/dU31uGkcEwTS+HH0=; b=z19y/melY9OgTt7a5+QOkwkxAVdcHkFeH/j2Rp5M2pdSa0yFJm022ejx08Ii6xhq7N tTw4u8MInZkDHXBVtDu7j7v29Nx7thxnWDs4myhSEonJal77SN+leoxAxhgh7amANOA2 V2BZtC99WO4ytH07mE0i5vcL/Wa7qMYg6chM4x9uommruc76yQZ3kst1DP+FTbFxl+q6 rvrR8QusLQMUuX/TvzsYcfAMxDlbyEczoHDOgnq3OCQZR0IN8ehfnPuLGN+Tk5osTnzK vBQuOtwTR7mq1q28HMftEB9dKXTl9BiRnbQ+lTKduaOp+BvhMX3kfNRhzcRXVdV0N0uv 97wQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :in-reply-to:user-agent; bh=n+bKjHvNfBsAR52qQoWih8gdjH/dU31uGkcEwTS+HH0=; b=MkT//XTVZwG/1BLTicYyWNE/AdviYiIk4UTqYHM7H//xgtVVt2jdMEfKG694e76IHU NB6KPHudWfH3M51QVTRoEK43HJW9WqwA+q0XaqW4LrcHmr7cZ3+9HFyyUFRPrLnG4vo6 MAr+hfQOK9esYMxT3dystVLAWDYmNS3oLjLnmcClvl4Wv1xfSSghq704ieDkkWfcJT01 3UjaPETIFgAJB+0uSRcmW87fplCZLRF2t/ifVPiDQn7UUasdUv7iuuu/UBrxWdNEBqpx zw/RLLRgCpvWZRj0PT3cGpyRSsTbAvjYN4LaIrwU3s6yrrgZU3Od0nioCgTWB52m6kzC cZoA== X-Gm-Message-State: AOPr4FUleySN1xvqs/u0Pcmy9qx2KNsBYxVKtt4/F1xF+fZq6tDXLGGFqaNIrKPJwJ0Rzg== X-Received: by 10.194.23.162 with SMTP id n2mr6251595wjf.108.1463565401449; Wed, 18 May 2016 02:56:41 -0700 (PDT) Received: from brick (abpx124.neoplus.adsl.tpnet.pl. [83.8.65.124]) by smtp.gmail.com with ESMTPSA id i1sm7757485wjm.12.2016.05.18.02.56.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 18 May 2016 02:56:40 -0700 (PDT) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Date: Wed, 18 May 2016 11:56:37 +0200 From: Edward Tomasz =?utf-8?Q?Napiera=C5=82a?= To: Warner Losh Cc: Alan Somers , "src-committers@freebsd.org" , "svn-src-all@freebsd.org" , "svn-src-head@freebsd.org" , "Kenneth D. Merry" Subject: Re: svn commit: r299371 - in head: sbin/camcontrol sys/cam sys/cam/scsi Message-ID: <20160518095637.GA3536@brick> Mail-Followup-To: Warner Losh , Alan Somers , "src-committers@freebsd.org" , "svn-src-all@freebsd.org" , "svn-src-head@freebsd.org" , "Kenneth D. Merry" References: <201605101546.u4AFkX0w073701@repo.freebsd.org> <20160510173351.GA4176@brick> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.1 (2016-04-27) 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: Wed, 18 May 2016 09:56:44 -0000 On 0517T1158, Warner Losh wrote: > 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. Indeed. But it would mean fixing "camcontrol rescan" first. > > 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. That's true. However, this hack is pretty non-intrusive - it only adds a trivial amount of code, and the "reprobe" command could be replaced with a simple alias to "rescan" if someone steps up to reimplement it. > 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. We have two clearly separated code paths, doing completely different things - one scanning the bus, and only notifying periph drivers if new device is discovered, and the other one to notify existing periph driver instances, without scanning anything. I just don't see how entangling them with each other would improve things. > and you didn't do ada like I asked. As I said in review, the ada(4) driver seems to lack resizing capability. It doesn't contain a call to disk_resize(9). It's been a few years since I've added resizing to da(4), but it took quite some time to make sure it interfaces with existing code in exactly the right way. I just don't have time for this kind of side quest right now. And I'm not even sure how to test it. With da(4) it was easy - I've just added LUN resizing to CTL. > Not happy with this at all, but not asking for a back out. Thanks.