Re: Possible bug in sbin/bsdlabel.c in -CURRENT

On Sun, Sep 19, 2004 at 11:01:25PM +0100, cbh-freebsd-current_at_groups.chrishedley.com wrote:
> Evening, chaps.
> 
> I don't think anyone's brought this one up yet, and it's a little 
> obscure... but for those of us who have MAXPARTITIONS set to a nonstandard 
> value (16 in my case, I need some extra as I'm using a largeish RAID array 
> that I'd like to chop into managable pieces), it seems that bsdlabel 
> randomly hiccups with a warning about the label length being wrong 
> ("disklabel: Wrong length label argument" after attempting to edit the 
> label, even without making any changes).  This only happens on certain 
> discs for reasons beyond my ken, but it seems that the culprit is circa 
> line 410 in sbin/bsdlabel/bsdlabel.c which currently says
> 
> 	gctl_ro_param(grq, "label", 148+16*8);
> 
> but which I'm guessing should say
> 
> 	gctl_ro_param(grq, "label", 148+16*MAXPARTITIONS);
> 
> The modification seems to work on my -CURRENT box without causing any 
> obvious harm, so I thought I'd mention it here to see what people think.
> 
> Cheers,
> 
> Chris.
> 
> PS Just to clarify, the discs which the unmodified disklabel worked on are 
> <40GB SCSI units attached to AIC 789x channels, and the one which it 
> didn't work on is a 450GB RAID-10 aac (2410SA) array.

IIRC you can't extend the number of partitions unless you don't need
boot blocks so this isn't all that useful except in situtations where
gpt(8) is a much better solution.  Fixing this hardcoding seems like a
reasionable idea, but I'm not an expert on this subject.  We're trying
to avoid stopgap hack to bsdlabel in general because it's an obviously
dead-end solution and we want to move on to something like GPT as soon
as feasiable.

-- Brooks

-- 
Any statement of the form "X is the one, true Y" is FALSE.
PGP fingerprint 655D 519C 26A7 82E7 2529  9BF0 5D8E 8BE9 F238 1AD4