From owner-freebsd-bugs@freebsd.org Sun Nov 29 20:50:47 2015 Return-Path: Delivered-To: freebsd-bugs@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 7B58BA3BC00 for ; Sun, 29 Nov 2015 20:50:47 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 614B61F86 for ; Sun, 29 Nov 2015 20:50:47 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id tATKolij079042 for ; Sun, 29 Nov 2015 20:50:47 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-bugs@FreeBSD.org Subject: [Bug 204901] GEOM doesn't see new disk capacity after VMDK resize without a reboot Date: Sun, 29 Nov 2015 20:50:47 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: mgrooms@shrew.net X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-bugs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter attachments.created Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Nov 2015 20:50:47 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204901 Bug ID: 204901 Summary: GEOM doesn't see new disk capacity after VMDK resize without a reboot Product: Base System Version: 11.0-CURRENT Hardware: amd64 OS: Any Status: New Severity: Affects Some People Priority: --- Component: kern Assignee: freebsd-bugs@FreeBSD.org Reporter: mgrooms@shrew.net Created attachment 163665 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=163665&action=edit patch that adds camcontrol reprobe device command ESXi allows the user to resize a VMDK attached to a running VM. Unfortunately it doesn't return any 'Unit Attention' sense information in response to a 'Read Capacity' request. This kinda makes sense as ESXi emulates SCSI-2 disk devices and, as far as I can tell, the 0x2A/0x09 ASC/ASCQ sense code that denotes 'Capacity Data Has Changed' wasn't defined until the SCSCI-3 spec. I am attaching a patch that allows an admin to request that a device be re-probed via camcontrol. The new command sends a CCB message that creates an async event. The event is captured by scsi_da which calls reprobe() on the peripheral, the same code that is executed when the 'Unit Attention' 'Capacity Data Has Changed' sense code is received from the device. For example ... # camcontrol readcap da1 -h Device Size: 32 G, Block Length: 512 bytes # gpart show da1 => 40 58720176 da1 GPT (28G) 40 58720176 1 freebsd-ufs (28G) Note, I resized the VMDK disk in ESXi. The camcontrol readcap output shows the size as 32G but geom still thinks its 28G. # camcontrol devlist at scbus1 target 0 lun 0 (cd0,pass0) at scbus2 target 0 lun 0 (pass1,da0) at scbus2 target 1 lun 0 (pass2,da1) at scbus3 target 0 lun 0 (da2,pass3) # camcontrol reprobe 2:1:0 The kernel output looks almost identical to when the 'Unit Attention' sense data is received ... Nov 28 17:46:13 iscsi-i kernel: (da1:mpt0:0:1:0): Re-probe requested Nov 28 17:46:13 iscsi-i kernel: GEOM_PART: da1 was automatically resized. Nov 28 17:46:13 iscsi-i kernel: Use `gpart commit da1` to save changes or `gpart undo da1` to revert them. Now that geom knows about the increased disk capacity, I can resize the partition and grow the fs ... [root@iscsi-i /home/mgrooms]# gpart show da1 => 40 67108784 da1 GPT (32G) 40 58720176 1 freebsd-ufs (28G) 58720216 8388608 - free - (4.0G) # gpart resize -i 1 da1 da1p1 resized # growfs da1p1 Device is mounted read-write; resizing will result in temporary write suspension for /var/data1. It's strongly recommended to make a backup before growing the file system. OK to grow filesystem on /dev/da1p1, mounted on /var/data1, from 28GB to 32GB? [Yes/No] Yes super-block backups (for fsck_ffs -b #) at: 58983232, 60265472, 61547712, 62829952, 64112192, 65394432, 66676672 # df -h Filesystem Size Used Avail Capacity Mounted on /dev/da0p3 18G 5.3G 12G 31% / devfs 1.0K 1.0K 0B 100% /dev /dev/da1p1 31G 32M 28G 0% /var/data1 /dev/da2p1 15G 32M 14G 0% /var/data2 -- You are receiving this mail because: You are the assignee for the bug.