Date: Mon, 20 Sep 2004 10:41:06 -0700 From: Brooks Davis <brooks@one-eyed-alien.net> To: cbh-freebsd-current@groups.chrishedley.com Cc: freebsd-current@freebsd.org Subject: Re: Possible bug in sbin/bsdlabel.c in -CURRENT Message-ID: <20040920174106.GB21687@odin.ac.hmc.edu> In-Reply-To: <20040919225036.B1582@teapot.cbhnet> References: <20040919225036.B1582@teapot.cbhnet>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --]
On Sun, Sep 19, 2004 at 11:01:25PM +0100, cbh-freebsd-current@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
[-- Attachment #2 --]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
iD8DBQFBTxYxXY6L6fI4GtQRApvMAJ95YDao3rAcYlVkxYMCoTvanT4lWQCdF3HP
9JuQ63yY3Agypq2fXt1ZAlQ=
=ChCy
-----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040920174106.GB21687>