funkiness when resizing a BSD slice

[Andrey V. Elsukov]

On 26.06.2013 11:31, Don Lewis wrote:
> I've got a machine that used to dual boot FreeBSD and a Fedora.  It had
> one disk slice for FreeBSD, another slice for Fedora, and a third slice
> that was marked as Linux swap that both FreeBSD and Linux used as swap.
> The FreeBSD slice had only an "a" ufs partition that covered the entire
> slice (in addition to the "c" partition).
> 
> FreeBSD outgrew its available space.  Since I wasn't using the Fedora
> slice anymore, I wanted to delete the Fedora slice, grow the FreeBSD
> slice, grow the "a" partition, and the run growfs to expand the ufs
> filesystem.  Things started off smoothly, but I ran into problems after
> I grew the FreeBSD slice.  I eventually stumbled around until I expanded
> the "a" partition, but then bsdlabel whined about the size of the "c"
> partition until I manually edited its size, contrary to the
> instructions.

Hi,

yes, the described problem exists. I see two ways how this can be solved.
1. geom resize method. It is called, when parent provider is growing. So
in some way this can be handled by each specific partitioning scheme.

2. Add to the gpart(8) and gpart(4) support to call gpart resize without
-i parameter (like this was done recently for set/unset attributes).
Without "-i" resize command will update partition table metadata, if it
contains some information about available size.


> I poked around inside the twistly little passages inside geom and I
> *think* the proper way to fix this is to add a resize method to
> g_bsd_class in geom_bsd.c.  I *think* this resize method should update
> d_secperunit in the disklabel at the start of the bsd slice, update
> gpt_last in the basetable, and update p_size in the "c" partition entry.

geom_bsd isn't used usually, it was replaced with g_part_bsd.

-- 
WBR, Andrey V. Elsukov