From owner-svn-src-all@freebsd.org Tue May 10 17:33:58 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 1424BB35E4C; Tue, 10 May 2016 17:33:58 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (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 9CB681227; Tue, 10 May 2016 17:33:57 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: by mail-wm0-x233.google.com with SMTP id e201so187784919wme.0; Tue, 10 May 2016 10:33:57 -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=svJslsDl4H4yjhf36ajDEAeVWx36R8gggA8awtccVvo=; b=ea7kXvkYf72M6aJsuMreJXrJLH8SwQqUJYlQpgsGaZqq2jwJ4zv69nwVnQ1ngAuS2W uPOfsAI4QY5BJBqzWryd1M2D2B8lfgwM8pT36XZ5W9J9N7mr1ppnW/IgCpfIoM4UX6bi t0VkcDooNxKFJFhe30wGw1mp5PNGQsGoFGjGyHdsXnN8KYPSVnoQNHCNC1LT1w/Egxg2 6zl8yeD+QdXsUXBpwabHpopJmEXjWVzTBkK0CfdDvv/n4ggVZ80nHPWQIFjp+WkJ7fvs kbrTM5rAS1B+07TLzoOzRYXjvrKypBiuGUS+oCaKQMUCORen3GL9vTjlixJYchVnx3Dx l7EQ== 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=svJslsDl4H4yjhf36ajDEAeVWx36R8gggA8awtccVvo=; b=Is/NaKbapJnFZKkg6yV05mYK0/5xiWLajoOQ9dfIa3wr/NPyVeSjyfRPYd5XtUVUnx OW+O4oU5AC+8yi0H2WGaVmWXMcpKI7NBbaRilo5UzNeyNJ/hUESWOP96Pa8l2jC+rzjk 61Iwtlq/1oplEkj/5w3xC331fpKUGoQ+mGL+QmaiFpHrRoxGha71CdLaKvZeN9yIBjTb VZjPwHhiFX7ycyWY4XdUgvxNlrAS4SUhx92gwHJgrb0AGgnLzv+iF3qjtDqJEp5oNIXZ igr9t+raFYn6qphJGngzfqp0Cy9yLmxdKpI3gXenomaOlDOHq+U0bxhrsGaox0EzTEiY HfWg== X-Gm-Message-State: AOPr4FW7SA38+1BGJCS0z64CG2obN/2kQEh7cSDCOGer+Z98Lxm5FrW2qaIPMPFYE1Vgig== X-Received: by 10.194.205.134 with SMTP id lg6mr39170585wjc.153.1462901635601; Tue, 10 May 2016 10:33:55 -0700 (PDT) Received: from brick (abuk109.neoplus.adsl.tpnet.pl. [83.8.182.109]) by smtp.gmail.com with ESMTPSA id u6sm3682299wjh.2.2016.05.10.10.33.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 10 May 2016 10:33:54 -0700 (PDT) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Date: Tue, 10 May 2016 19:33:51 +0200 From: Edward Tomasz Napierala To: Alan Somers Cc: "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: <20160510173351.GA4176@brick> Mail-Followup-To: 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) 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, 10 May 2016 17:33:58 -0000 On 0510T1020, Alan Somers wrote: > On Tue, May 10, 2016 at 9:46 AM, Edward Tomasz Napierala > 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).