resampeling of a ZVOL that has been resized

[Willem Jan Withagen]

On 27/04/2015 19:26, Willem Jan Withagen wrote:
> 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.

It has been running for most the day and night, in all kinds of
incarnations....

And it has not failed yet and without crashes.
So I'd say: that is a fix.

--WjW