Date: Mon, 27 Apr 2015 12:18:08 +0200 From: Adam Nowacki <nowakpl@platinum.linux.pl> To: freebsd-fs@freebsd.org Subject: Re: resampeling of a ZVOL that has been resized Message-ID: <553E0CE0.8070803@platinum.linux.pl> In-Reply-To: <553B7200.7090002@digiware.nl> References: <55381127.4090603@digiware.nl> <5539B0C4.6070000@yandex.ru> <553B7200.7090002@digiware.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2015-04-25 12:52, Willem Jan Withagen wrote: > On 24/04/2015 04:56, Andrey V. Elsukov wrote: >> On 23.04.2015 00:22, Willem Jan Withagen wrote: >>> Now the question: >>> How can I get GEOM to resample the zvol, and have it really detect that >>> the disk has changed.... It sort of does, but not enough to actually >>> allow it to grow to the new size. >> >> You need to read dmesg, where you will find the message: >> GEOM_PART: zvol/zfsdata/vol was automatically resized. >> Use `gpart commit zvol/zfsdata/vol` to save changes or >> `gpart undo zvol/zfsdata/vol` to revert them. >> > > This does not really resolve the issue. > after growing the volume in ZFS, the new size is reported in ' > gpart show': > > freetest# gpart show zvol/zfsdata/vol > => 40 209715120 zvol/zfsdata/vol GPT (200G) > 40 8 - free - (4.0K) > 48 209715104 1 freebsd-ufs (100G) > 209715152 8 - free - (4.0K) > > However the free space at the end stays at a mere 4.0K, not allowing > gpart resize to take any value other than less than 100G, effectively > shrinking the partition. > > And there is no incantation of any of commit, recover, etc... to get > gpart to actually do "the right thing" > > When I did this on a VMware VM, gpart show reported the volume as > [CORRUPTED] and gpart recover fixed that. > Supposedly the backup blocks were at the wrong place in the grown disk > and recover again placed them at the end. > > But the ZFS case does not go into the [CORRUPTED] state. > Perhaps that is due to also missing the message that you suggest that > can be found in dmesg after resizing the ZVOL. > And thus a recover is not needed, nor dies issueing it fix anything. > > Now after a reboot the bootup log tells: > GEOM: zvol/zfsdata/vol: the secondary GPT header is not in the last LBA. > > And now gpart report as expected: > => 40 209715120 zvol/zfsdata/vol GPT (200G) [CORRUPT] > 40 8 - free - (4.0K) > 48 209715104 1 freebsd-ufs (100G) > 209715152 8 - free - (4.0K) > > gpart recover sets the free space to 100G: > => 40 419430320 zvol/zfsdata/vol GPT (200G) > 40 8 - free - (4.0K) > 48 209715104 1 freebsd-ufs (100G) > 209715152 209715208 - free - (100G) > > And from now on I can resize the partition 1 to 200G... > > So it seems that although gpart understands that the ZVOL volume has > grown, it does not take it far enough and set it to CORRUPTED and then > let the user correct/grow it. You can tell kernel to retaste the device without rebooting by running: true > /dev/zvol/zfsdata/vol
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?553E0CE0.8070803>