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