From owner-freebsd-geom@freebsd.org Fri Jul 8 15:20:27 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 ABC98B85CF5 for ; Fri, 8 Jul 2016 15:20:27 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (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 725F01226 for ; Fri, 8 Jul 2016 15:20:27 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: by mail-io0-x232.google.com with SMTP id s93so4257006ioi.3 for ; Fri, 08 Jul 2016 08:20:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sippysoft-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=HXofvCRTPQpGmiALrU5AvlDCXSfzOGFP+bVeYZHaNhw=; b=QOZneCMqyIJQaiPiib25W2WaLDY2h7WKOCycCFS01/TR4ToT4fYQcuaXl40IuQErLL 1A+GJAKUKGMMhREeHWoFy8BGsyMsbVMBgFM0J9HH/pAymczF3c3Gj0LckrBjCC/LjU0E uefyK+RCRyZAAHl+1Oqt8SnP6d54iSnNEWtFpw/+HbN1cYM5Ds54ujawYUlLM9vZeBvQ DvUleEItwygBNiChvik8Itnsxktu2aJv6ieHZib0ZoKBNvTYTzf00BYHJMgzr66Ug2Go bbRS5A5xOuL8JCymC/cwJMR1V8WufBz0QlCtoi2PxlqGHQkCe5QUUoHDkPuiemNfQe++ k+XQ== 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; bh=HXofvCRTPQpGmiALrU5AvlDCXSfzOGFP+bVeYZHaNhw=; b=AX5u6Hj5gAFLZMITViR39MO4xqnXfmzGDXpBA8QKXkxLFtic9kp4fDnLzMN5I1UUK8 D5Qfon+oK5NzIgBhtkl/mFuE30GL6kuNen3UgxPdSNEIpFH3GJvy9F9HEpNzs3TxLooI YicR6ucJi1ozzXj7AD/Bk+/NS0CN6X2ENWI4scqwUZMoWGoAP9DoicVJsroAb4c1Xjj2 aXGanw2663oAb9Ugv7Ej/UjYsgaWXJi6Xl2nOjcnRcp993xZ8r48nnYuHWena9gLMDVp ndyHajrK3RKPEWR841YZs+HlwkAR2WyJuBg/21EOvKzBhaa5GfRi+m542KEMcShuN3bN KOYg== X-Gm-Message-State: ALyK8tI3dyZ8jA4QGlPSAOCT35evnWeKNBCEBK5mO6oQXXZ/Wj18+tgmIKjCFqwQkfO00phBUcWUAxpdG0CLdZpK X-Received: by 10.107.16.142 with SMTP id 14mr8693859ioq.142.1467991226794; Fri, 08 Jul 2016 08:20:26 -0700 (PDT) MIME-Version: 1.0 Sender: sobomax@sippysoft.com Received: by 10.36.59.193 with HTTP; Fri, 8 Jul 2016 08:20:26 -0700 (PDT) In-Reply-To: References: From: Maxim Sobolev Date: Fri, 8 Jul 2016 08:20:26 -0700 X-Google-Sender-Auth: WTlavPelMKnHymh8wmZWD0vvB1g 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 , ken , imp , Hongjiang Zhang , Sepherosa Ziehau Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.22 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 15:20:27 -0000 Smells like a bug in the geom_part where it supposed to re-read the partitions and update its internal structures. The reason why it works when you open dev/da1 for writing is because the geom_part provider that is attached to that disk is destroyed and created anew when you close the fd. -Maxim On Fri, Jul 8, 2016 at 5:19 AM, Dexuan Cui wrote: > Hi, I have a FreeBSD virtual machine (VM) running on Hyper-V and I'm > testing Hyper-V's Disk Online Resizing feature. The feature can expand or > shrink 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 > space displayed by gpart remained the same unless I open the disk dev file > for writing, e.g., > > [root@decui-bsd11 ~]# gpart create -s MBR /dev/da1 > da1 created > [root@decui-bsd11 ~]# gpart show /dev/da1 > => 63 83886017 da1 MBR (40G) > 63 83886017 - free - (40G) > [root@decui-bsd11 ~]# diskinfo /dev/da1 > /dev/da1 512 42949672960 83886080 4096 0 > 5221 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, but > the free space remains the same. > (Note: the first diskinfo failure should be expected: Hyper-V only > notifies the VM of the capacity change on the VM's next read or write > request, and in the VM it seems there is a race condition between the ioctl > and the handling 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 > 6527 255 63 > > [root@decui-bsd11 ~]# gpart show /dev/da1 > => 63 83886017 da1 MBR (50G) > 63 83886017 - free - (40G) > > Now, if I run a program that only does > "openat(AT_FDCWD,"/dev/da1",O_WRONLY|O_CREAT,0644);", GEOM will detect that > the free space is 50GB now and GEOM will pass this info to gpart: > > [root@decui-bsd11 ~]# gpart show /dev/da1 > => 63 104857537 da1 MBR (50G) > 63 104857537 - free - (50G) > > I'm not familiar with GEOM. > Can somebody please explain the behavior? > > I don't know who exactly maintains GEOM , so I just picked some names from > "git log geom/" and put you to Cc. Sorry if this mail bothers you. :-) > > Thanks, > -- Dexuan > >