From owner-freebsd-scsi@FreeBSD.ORG Mon Dec 16 17:41:40 2013 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 94AF2A13 for ; Mon, 16 Dec 2013 17:41:40 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 72A24167E for ; Mon, 16 Dec 2013 17:41:40 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id rBGHfdiw077727 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Dec 2013 09:41:39 -0800 (PST) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id rBGHfdPl077726; Mon, 16 Dec 2013 09:41:39 -0800 (PST) (envelope-from jmg) Date: Mon, 16 Dec 2013 09:41:39 -0800 From: John-Mark Gurney To: Douglas Gilbert Subject: Re: camcontrol rescan not updating disk size? Message-ID: <20131216174139.GA55638@funkthat.com> Mail-Followup-To: John-Mark Gurney , Douglas Gilbert , Rolf Grossmann , freebsd-scsi@freebsd.org References: <52AF2DE0.70101@progtech.net> <52AF380A.30407@interlog.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <52AF380A.30407@interlog.com> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Mon, 16 Dec 2013 09:41:39 -0800 (PST) Cc: freebsd-scsi@freebsd.org, Rolf Grossmann X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Dec 2013 17:41:40 -0000 Douglas Gilbert wrote this message on Mon, Dec 16, 2013 at 12:27 -0500: > On 13-12-16 11:44 AM, Rolf Grossmann wrote: > >Hi, > > > >I'm having a problem with a virtualized system. I've grown the virtual > >disk, but my FreeBSD 9.1-STABLE r246991 won't recognize the new size: > > > ># grep da1 /var/run/dmesg.boot > >da1 at mpt0 bus 0 scbus2 target 1 lun 0 > >da1: Fixed Direct Access SCSI-2 device > >da1: 320.000MB/s transfers (160.000MHz DT, offset 127, 16bit) > >da1: Command Queueing enabled > >da1: 75776MB (155189248 512 byte sectors: 255H 63S/T 9660C) > > > ># camcontrol readcap 2:1:0 > >Last Block: 314572799, Block Length: 512 bytes > > > ># camcontrol rescan 2:1:0 > >Re-scan of 2:1:0 was successful > > > ># geom disk list da1 > >Geom name: da1 > >Providers: > >1. Name: da1 > > Mediasize: 79456894976 (74G) > > Sectorsize: 512 > > Mode: r1w1e1 > > descr: VMware Virtual disk > > ident: (null) > > fwsectors: 63 > > fwheads: 255 > > > >IMHO that should now read "Mediasize: 161061273088 (150G)". > > > >(What I'm actually trying to do is "zpool online -e mypool da1", but > >that doesn't recognize the new size either, so I'm thinking geom is a > >good indicator of the system's idea of the disk size.) > > > >I've tried a full and targetd rescan multiple times to no avail. I don't > >see anything to rescan the size or flush some sort of cache. My Google > >searches also came up empty. I'm out of ideas what else to try short of > >a reboot (which I'd really like to avoid). > > A related point: according to sbc3r36.pdf when an LU changes its > size then it should "establish a unit attention condition with an > additional sense code set to CAPACITY DATA HAS CHANGED". Can you > determine if that happens? If it does then CAM needs enhancing, if > not targetd needs some work. Just a quick search of the CAM code, and it looks like -HEAD does handle the CAPACITY DATA HAS CHANGED message.. sys/scsi/scsi_da.c:3537... A reboot would definately fix it, though it sounds like you're trying to avoid that... It also looks like a reopen of the device would reprobe the size... You could try to zpool replace w/ it self, but that might not cause a reopen, or if it's part of a mirror/raidz volume, you could offline/online the device and then it should have the new sizes... In my experience, zfs will detect the device already has valid data on it, and not have to resilver the whole device, but as usual, make sure you have good backups.. :) A zpool export/import would obviously do the same thing... Hope this helps. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not."