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
--OwLcNYc0lM97+oe1
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Sun, Sep 19, 2004 at 11:01:25PM +0100, cbh-freebsd-current@groups.chrish=
edley.com wrote:
> Evening, chaps.
>=20
> I don't think anyone's brought this one up yet, and it's a little=20
> obscure... but for those of us who have MAXPARTITIONS set to a nonstandar=
d=20
> value (16 in my case, I need some extra as I'm using a largeish RAID arra=
y=20
> that I'd like to chop into managable pieces), it seems that bsdlabel=20
> randomly hiccups with a warning about the label length being wrong=20
> ("disklabel: Wrong length label argument" after attempting to edit the=20
> label, even without making any changes). This only happens on certain=20
> discs for reasons beyond my ken, but it seems that the culprit is circa=
=20
> line 410 in sbin/bsdlabel/bsdlabel.c which currently says
>=20
> gctl_ro_param(grq, "label", 148+16*8);
>=20
> but which I'm guessing should say
>=20
> gctl_ro_param(grq, "label", 148+16*MAXPARTITIONS);
>=20
> The modification seems to work on my -CURRENT box without causing any=20
> obvious harm, so I thought I'd mention it here to see what people think.
>=20
> Cheers,
>=20
> Chris.
>=20
> PS Just to clarify, the discs which the unmodified disklabel worked on ar=
e=20
> <40GB SCSI units attached to AIC 789x channels, and the one which it=20
> 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
--=20
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
--OwLcNYc0lM97+oe1
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
iD8DBQFBTxYxXY6L6fI4GtQRApvMAJ95YDao3rAcYlVkxYMCoTvanT4lWQCdF3HP
9JuQ63yY3Agypq2fXt1ZAlQ=
=ChCy
-----END PGP SIGNATURE-----
--OwLcNYc0lM97+oe1--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040920174106.GB21687>