resampeling of a ZVOL that has been resized

Willem Jan Withagen wjw at digiware.nl
Mon Apr 27 17:26:38 UTC 2015


On 27/04/2015 10:57, Andrey V. Elsukov wrote:
> On 25.04.2015 13:52, Willem Jan Withagen wrote:
>> 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.
> 
> Can you try this patch?
> 
> Index: head/sys/geom/part/g_part_gpt.c
> ===================================================================
> --- head/sys/geom/part/g_part_gpt.c	(revision 282044)
> +++ head/sys/geom/part/g_part_gpt.c	(working copy)
> @@ -760,7 +760,7 @@ g_part_gpt_resize(struct g_part_table *basetable,
>  	struct g_part_gpt_entry *entry;
> 
>  	if (baseentry == NULL)
> -		return (EOPNOTSUPP);
> +		return (g_part_gpt_recover(basetable));
> 
>  	entry = (struct g_part_gpt_entry *)baseentry;
>  	baseentry->gpe_end = baseentry->gpe_start + gpp->gpp_size - 1;
> 

That actually generates on the console: (And probably in dmesg)
Apr 27 15:35:37 freetest kernel: GEOM_PART: zvol/zfsdata/vol was
automatically resized.
Apr 27 15:35:37 freetest kernel: Use `gpart commit zvol/zfsdata/vol` to
save changes or `gpart undo zvol/zfsdata/vol` to revert them.

And after gpart commit, it allows to gpart resize, growfs..
Exactly like I wanted. But I need to set
	freetest# sysctl kern.geom.debugflags=16
before resize actually works.

And I did get a panic in one of the attempts, but with no keyboard to
the console. So I had very little to act on, and needed to reset.

I'll finish the test script and run it in a loop to see if the panic
reoccurs.

But so far so good.
--WjW






More information about the freebsd-fs mailing list