From owner-freebsd-geom@freebsd.org Fri Jul 8 18:03:25 2016 Return-Path: Delivered-To: freebsd-geom@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 7B21CB853E7 for ; Fri, 8 Jul 2016 18:03:25 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::234]) (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 4BD921752 for ; Fri, 8 Jul 2016 18:03:25 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x234.google.com with SMTP id h190so15476468ith.1 for ; Fri, 08 Jul 2016 11:03:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=Bao8I4BHBBmFu2DW6HaXuXqC9Vf3tBxi/IuEftX++ZY=; b=orHb0f3mG47m29JcwA1tVDiSSCntNJp0eAFyY+Y0ocpahQx6LRrBZ3p9nMAnx08LOa hC8KomMcLo4Qj3M8cXamrGSSbw7Ru+ggWariw0sDszuqf5O2lnVucRUTIttSCaK3EiC2 f2bnIe1SGyk6rA/gLCOZ6BX5DLishcVSTLWomh9VcPNdK4NWfI7HURkpyqCfs9QwrhTN DES569i4Ss/tH2ddGK7geP3v9h7KL9g33dW/zgYW8U9XpkuZK4ouptE+aW5dDmEUGOr4 Nj1RiL7X3dPJfFJaih2mjppRfKeC8mjZECrINGJBm5IgSuvmBpKIuf0MyPXWIgTal+We J/EQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-transfer-encoding; bh=Bao8I4BHBBmFu2DW6HaXuXqC9Vf3tBxi/IuEftX++ZY=; b=AlzilTWhNBavdOZZuE55AIr3mYgdlSA3dVVJyOezpzoVY1hnY/Z5w6FiolBoARC+2z vkwOkYLapMHKnYJlWyWxrKIWgsj4/OFwmRCDbw+dTkxOTIfGeoQmlnFBL3NOtgIR/2Os kyVn9ebCiLN0R0MuIx4Pg/g2irkbaCussRSo+bCDVkJFC9tDJPIJbuYgRCbZeXVhLyGj lblC2Q+yAmh6s24fpkxiVIVdzUOvi1/z6v+Uo05lOL7qHGU2VCBKIF3ntiIfFsnU18Bk cA+cI9mDCvGhHHYDGCE8jYDAu1SG5VhhjF05jT+e+G0JQFakfJhplU3v9a/Ag7TMQf2A eUKg== X-Gm-Message-State: ALyK8tIn2qUVuaSqFHZja8MpZWvLNbZ3IlfNaaZEmMNmORGDd8i0UwZ8MaZElDctHb62keCgM6n1HfQMFOlT8g== X-Received: by 10.36.41.16 with SMTP id p16mr4937627itp.60.1468001004596; Fri, 08 Jul 2016 11:03:24 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.137.131 with HTTP; Fri, 8 Jul 2016 11:03:24 -0700 (PDT) X-Originating-IP: [69.53.245.200] In-Reply-To: References: From: Warner Losh Date: Fri, 8 Jul 2016 12:03:24 -0600 X-Google-Sender-Auth: soMb7Hv_06mIW0bfPCxpjNsvLVM Message-ID: Subject: Re: How to force GEOM to recalculate the free space after the disk is resized? To: Dexuan Cui Cc: "freebsd-geom@freebsd.org" , Allan Jude , sobomax , ken , imp , Hongjiang Zhang , Sepherosa Ziehau Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 18:03:25 -0000 On Fri, Jul 8, 2016 at 6:19 AM, Dexuan Cui wrote: > Hi, I have a FreeBSD virtual machine (VM) running on Hyper-V and I'm test= ing Hyper-V's Disk Online Resizing feature. The feature can expand or shrin= k the (virtual) disk capacity of a VM when the VM is running. > > There is an issue with gpart or GEOM: after the disk capacity is expanded= (or shrunk), gpart/GEOM can detect the new bigger capacity, but the free s= pace displayed by gpart remained the same unless I open the disk dev file f= or writing, e.g., > > [root@decui-bsd11 ~]# gpart create -s MBR /dev/da1 > da1 created > [root@decui-bsd11 ~]# gpart show /dev/da1 > =3D> 63 83886017 da1 MBR (40G) > 63 83886017 - free - (40G) > [root@decui-bsd11 ~]# diskinfo /dev/da1 > /dev/da1 512 42949672960 83886080 4096 0 5= 221 255 63 > > Now I expand the disk from 40GB to 50GB by Hyper-V management tool. > > Next, I get the below, i.e., gpart/GEOM detects the new disk capacity, bu= t the free space remains the same. > (Note: the first diskinfo failure should be expected: Hyper-V only notifi= es the VM of the capacity change on the VM's next read or write request, an= d in the VM it seems there is a race condition between the ioctl and the ha= ndling of capacity change. I'll see how this can be fixed.) > > [root@decui-bsd11 ~]# diskinfo /dev/da1 > diskinfo: /dev/da1: ioctl(DIOCGMEDIASIZE) failed, probably not a disk. > [root@decui-bsd11 ~]# diskinfo /dev/da1 > /dev/da1 512 53687091200 104857600 4096 0 6= 527 255 63 > > [root@decui-bsd11 ~]# gpart show /dev/da1 > =3D> 63 83886017 da1 MBR (50G) > 63 83886017 - free - (40G) > > Now, if I run a program that only does "openat(AT_FDCWD,"/dev/da1",O_WRON= LY|O_CREAT,0644);", GEOM will detect that the free space is 50GB now and GE= OM will pass this info to gpart: > > [root@decui-bsd11 ~]# gpart show /dev/da1 > =3D> 63 104857537 da1 MBR (50G) > 63 104857537 - free - (50G) > > I'm not familiar with GEOM. > Can somebody please explain the behavior? I'm guessing that the new code in the da driver to do 'resize' isn't proper= ly signaling up the stack so that GEOM re-tastes the drive. The resize code was just recently added to camcontrol (I'm assuming that's what you are using to force the da driver to requery the size).a Geom normally retastes the drive when it closes after it has been opened for writing, which is why your open hack works. Warner