From owner-freebsd-geom@freebsd.org Fri Jul 8 13:53:15 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 2E2D7B845BD for ; Fri, 8 Jul 2016 13:53:15 +0000 (UTC) (envelope-from decui@microsoft.com) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0114.outbound.protection.outlook.com [104.47.37.114]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DAA0412F2; Fri, 8 Jul 2016 13:53:14 +0000 (UTC) (envelope-from decui@microsoft.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=GArmtuHAayg+nbeEDY3/Cuz0NC3Kt+nnCwo540QS2+c=; b=YJuNPUzAu8+9Uow7Lk8xO3yfARGu9TLAZcT+wUbd7c9HAxEODjXVmJwnD4qkcYFSwuwMsga7EjCZ1logK7tuhUtd1XdveMXpo7psHGxocZyHqya8rNsKMo1CTthAkVpIuCSvXwGfif/+DlpYQ19cpPWW7dPRg5+xzia9l9azOK8= Received: from CO2PR03MB2182.namprd03.prod.outlook.com (10.166.92.17) by CO2PR03MB2213.namprd03.prod.outlook.com (10.166.92.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.528.16; Fri, 8 Jul 2016 12:19:01 +0000 Received: from CO2PR03MB2182.namprd03.prod.outlook.com ([10.166.92.17]) by CO2PR03MB2182.namprd03.prod.outlook.com ([10.166.92.17]) with mapi id 15.01.0534.020; Fri, 8 Jul 2016 12:19:01 +0000 From: Dexuan Cui To: "freebsd-geom@freebsd.org" CC: Allan Jude , sobomax , ken , imp , Hongjiang Zhang , Sepherosa Ziehau Subject: How to force GEOM to recalculate the free space after the disk is resized? Thread-Topic: How to force GEOM to recalculate the free space after the disk is resized? Thread-Index: AdHZDRzvMnaRHenxQ+mzWQWfArdlkw== Date: Fri, 8 Jul 2016 12:19:01 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=decui@microsoft.com; x-originating-ip: [2404:f801:9000:19::5e6] x-ms-office365-filtering-correlation-id: c45b8368-0e0a-4099-cc8a-08d3a72a0ba5 x-microsoft-exchange-diagnostics: 1; CO2PR03MB2213; 6:7cJwbnSJrpNl+LfgDJLxo0XebqIn6KHSqNgdtewelja+ZrHrDrOBU4lmjFUsO6Qv0zETOmbBLVYvSld3x5pUc8JPGybI+0xQtCNHV1cKyx19JWwFVENXib25zQfW4Fzom+5fBNgWAOGj24Yqe4kmOh5GA6sqWx5L3VKW0Dx6sHXpTHf142qxc3FkVRfnoWFZK5btT2bLpeL9TR3DJUCSavlvK0t56ISlZlE6mpbAYUP1WTs5X7OY7VSA8yb7wn35EzVbx1wj22B1kWMStzcUvhS6pe53Kud+HaGVLFN93HY5OauWdlU0cvIBGgDZpNhbQEsJ5vn+UQHAJiBrVDs1kQ==; 5:TRJDvdHNzcDBL/ViyTc30KY3RmqFeK0WCeltT+vtgQu+Zs+gH+r1IpDYOW4tDkqIfUg/dr8wFdTwQyiPSmoSQN1LeF6oj0nI2ye1ERCTEUf2lXz1tFao44+hUaThXTsWH3uaQGCuWV2cjrAogt0RiQ==; 24:pS3gzoD7cWjBWUpTqLIuRcmiskeixkum2B/ZXtxvM7fEMEcoQcml8DF+XKQnuKCb8/oAbxBPosyatFrC2j9cO/FFPwkrhOtdIaquoc3UHq0=; 7:5xns9XYhZTUMkxfjOt747EAE54cSh43t56zoMH0KfqlKgY/BaBAmfHPMqIDD2MmmvO4jVz3UWbqRWzvX+rCmF00JoJdD7/C31TBLubsgqUhm0YUmTO/TcqxYfbC7abnlRP9nKpF/rFo36ZssYNGjzE0g52kbKKxmz3uOTuEt7JIaP7RjrcaBjoS4akCxB4tQRHyO1oNtSpLV1IWN9m0jk5O4zIizBkLlptS1jR+6vvdt5DWGVsaG39x8ILa9Nk29 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO2PR03MB2213; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(209352067349851); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:CO2PR03MB2213; BCL:0; PCL:0; RULEID:; SRVR:CO2PR03MB2213; x-forefront-prvs: 0997523C40 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(6009001)(7916002)(189002)(199003)(50986999)(2501003)(92566002)(4326007)(74316002)(5640700001)(9686002)(106356001)(305945005)(54356999)(19580405001)(2900100001)(110136002)(97736004)(87936001)(81156014)(6116002)(2906002)(10090500001)(99286002)(8676002)(81166006)(76576001)(11100500001)(101416001)(102836003)(5005710100001)(8990500004)(10290500002)(33656002)(10400500002)(3280700002)(86362001)(122556002)(3660700001)(77096005)(8936002)(189998001)(105586002)(229853001)(5003600100003)(2351001)(586003)(68736007)(7846002)(7696003)(86612001)(5002640100001)(7736002)(3826002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR03MB2213; H:CO2PR03MB2182.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jul 2016 12:19:01.3850 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR03MB2213 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 13:53:15 -0000 Hi, I have a FreeBSD virtual machine (VM) running on Hyper-V and I'm testin= g 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 spa= ce 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 =3D> 63 83886017 da1 MBR (40G) 63 83886017 - free - (40G) [root@decui-bsd11 ~]# diskinfo /dev/da1 /dev/da1 512 42949672960 83886080 4096 0 522= 1 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 hand= ling 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 652= 7 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_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 =3D> 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