NetBSD Problem Report #2675

From gnats  Mon Aug  5 16:12:44 1996
Received: from Collatz.McRCIM.McGill.EDU by pain.lcs.mit.edu (8.7.5/8.7.3) with SMTP id PAA22148 for <gnats-bugs@gnats.netbsd.org>; Mon, 5 Aug 1996 15:53:45 -0400 (EDT)
Message-Id: <199608051953.PAA03580@Collatz.McRCIM.McGill.EDU>
Date: Mon, 5 Aug 1996 15:53:38 -0400
From: der Mouse <mouse@Collatz.McRCIM.McGill.EDU>
Reply-To: mouse@Collatz.McRCIM.McGill.EDU
To: gnats-bugs@NetBSD.ORG
Subject: [dM] 8 partitions is awfully few
X-Send-Pr-Version: 3.2

>Number:         2675
>Category:       kern
>Synopsis:       [dM] 8 partitions is awfully few
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    port-sparc-maintainer
>State:          open
>Class:          change-request
>Submitter-Id:   net
>Arrival-Date:   Mon Aug 05 16:20:03 +0000 1996
>Closed-Date:    
>Last-Modified:  Mon Feb 09 09:11:58 +0000 2015
>Originator:     der Mouse
>Release:        1.2
>Organization:
	Dis-
>Environment:
	Any SPARC (I use an IPC)
>Description:
	Especially with the advent of modern disks with sizes up around
	4G and 9G and the like, 8 partitions per disk seems awfully
	few.
>How-To-Repeat:
	Try to split up a big disk.  Find yourself constrained by the
	seven-partition limit (eight including c).  Sigh.
>Fix:
	Here's what I've done.  It seems to work reasonably well.  I've
	tucked the "other" eight partitions in the spare space in the
	disklabel between the ASCII label string and the RPM value,
	with a magic number and a checksum.  If either magic or
	checksum is wrong, the "extended" eight partitions are all 0
	offset 0 size.

	The disksubr.c patch includes a fix to bounds_check_with_label;
	I think I saw a commit message indicating this - or something
	like it - went into the main branch, but it hasn't yet showed
	up in the sups.  I'm including it here on the theory that
	anyone who is into fiddling with disk labeling to the point of
	sixteen partitions probably also wants this fix. :-)

	I'm not sure I've done all that's necessary to MAKEDEV; I'd
	appreciate any remarks from those who know.

--- OLD/etc/etc.sparc/MAKEDEV	Thu Jan  1 00:00:00 1970
+++ NEW/etc/etc.sparc/MAKEDEV	Thu Jan  1 00:00:00 1970
@@ -167,27 +167,42 @@
 	vnd*) name=vnd; blk=8; chr=110;;
 	esac
 	case $unit in
-	0|1|2|3|4|5|6|7|8|9|10|11|12|13|14|15|16|\
-	17|18|19|20|21|22|23|24|25|26|27|28|29|30|31)
-		rm -f ${name}${unit}[a-h] r${name}${unit}[a-h]
-		mknod ${name}${unit}c	b $blk `expr $unit '*' 8 + 2`
-		mknod r${name}${unit}c	c $chr `expr $unit '*' 8 + 2`
-		mknod ${name}${unit}a	b $blk `expr $unit '*' 8 + 0`
-		mknod ${name}${unit}b	b $blk `expr $unit '*' 8 + 1`
-		mknod ${name}${unit}d	b $blk `expr $unit '*' 8 + 3`
-		mknod ${name}${unit}e	b $blk `expr $unit '*' 8 + 4`
-		mknod ${name}${unit}f	b $blk `expr $unit '*' 8 + 5`
-		mknod ${name}${unit}g	b $blk `expr $unit '*' 8 + 6`
-		mknod ${name}${unit}h	b $blk `expr $unit '*' 8 + 7`
-		mknod r${name}${unit}a	c $chr `expr $unit '*' 8 + 0`
-		mknod r${name}${unit}b	c $chr `expr $unit '*' 8 + 1`
-		mknod r${name}${unit}d	c $chr `expr $unit '*' 8 + 3`
-		mknod r${name}${unit}e	c $chr `expr $unit '*' 8 + 4`
-		mknod r${name}${unit}f	c $chr `expr $unit '*' 8 + 5`
-		mknod r${name}${unit}g	c $chr `expr $unit '*' 8 + 6`
-		mknod r${name}${unit}h	c $chr `expr $unit '*' 8 + 7`
-		chgrp operator ${name}${unit}[a-h] r${name}${unit}[a-h]
-		chmod 640 ${name}${unit}[a-h] r${name}${unit}[a-h]
+	0|1|2|3|4|5|6|7|8|9|10|11|12|13|14|15)
+		rm -f ${name}${unit}[a-p] r${name}${unit}[a-p]
+		mknod ${name}${unit}c	b $blk `expr $unit '*' 16 + 2`
+		mknod r${name}${unit}c	c $chr `expr $unit '*' 16 + 2`
+		mknod ${name}${unit}a	b $blk `expr $unit '*' 16 + 0`
+		mknod ${name}${unit}b	b $blk `expr $unit '*' 16 + 1`
+		mknod ${name}${unit}d	b $blk `expr $unit '*' 16 + 3`
+		mknod ${name}${unit}e	b $blk `expr $unit '*' 16 + 4`
+		mknod ${name}${unit}f	b $blk `expr $unit '*' 16 + 5`
+		mknod ${name}${unit}g	b $blk `expr $unit '*' 16 + 6`
+		mknod ${name}${unit}h	b $blk `expr $unit '*' 16 + 7`
+		mknod ${name}${unit}i	b $blk `expr $unit '*' 16 + 8`
+		mknod ${name}${unit}j	b $blk `expr $unit '*' 16 + 9`
+		mknod ${name}${unit}k	b $blk `expr $unit '*' 16 + 10`
+		mknod ${name}${unit}l	b $blk `expr $unit '*' 16 + 11`
+		mknod ${name}${unit}m	b $blk `expr $unit '*' 16 + 12`
+		mknod ${name}${unit}n	b $blk `expr $unit '*' 16 + 13`
+		mknod ${name}${unit}o	b $blk `expr $unit '*' 16 + 14`
+		mknod ${name}${unit}p	b $blk `expr $unit '*' 16 + 15`
+		mknod r${name}${unit}a	c $chr `expr $unit '*' 16 + 0`
+		mknod r${name}${unit}b	c $chr `expr $unit '*' 16 + 1`
+		mknod r${name}${unit}d	c $chr `expr $unit '*' 16 + 3`
+		mknod r${name}${unit}e	c $chr `expr $unit '*' 16 + 4`
+		mknod r${name}${unit}f	c $chr `expr $unit '*' 16 + 5`
+		mknod r${name}${unit}g	c $chr `expr $unit '*' 16 + 6`
+		mknod r${name}${unit}h	c $chr `expr $unit '*' 16 + 7`
+		mknod r${name}${unit}i	c $chr `expr $unit '*' 16 + 8`
+		mknod r${name}${unit}j	c $chr `expr $unit '*' 16 + 9`
+		mknod r${name}${unit}k	c $chr `expr $unit '*' 16 + 10`
+		mknod r${name}${unit}l	c $chr `expr $unit '*' 16 + 11`
+		mknod r${name}${unit}m	c $chr `expr $unit '*' 16 + 12`
+		mknod r${name}${unit}n	c $chr `expr $unit '*' 16 + 13`
+		mknod r${name}${unit}o	c $chr `expr $unit '*' 16 + 14`
+		mknod r${name}${unit}p	c $chr `expr $unit '*' 16 + 15`
+		chgrp operator ${name}${unit}[a-p] r${name}${unit}[a-p]
+		chmod 640 ${name}${unit}[a-p] r${name}${unit}[a-p]
 		;;
 	*)
 		echo bad unit for disk in: $i

--- OLD/sys/arch/sparc/include/disklabel.h	Thu Jan  1 00:00:00 1970
+++ NEW/sys/arch/sparc/include/disklabel.h	Thu Jan  1 00:00:00 1970
@@ -35,7 +35,7 @@

 #define	LABELSECTOR	0			/* sector containing label */
 #define	LABELOFFSET	64			/* offset of label in sector */
-#define	MAXPARTITIONS	8			/* number of partitions */
+#define	MAXPARTITIONS	16			/* number of partitions */
 #define	RAW_PART	2			/* raw partition: xx?c */

 struct cpu_disklabel {

--- OLD/sys/arch/sparc/include/sun_disklabel.h	Thu Jan  1 00:00:00 1970
+++ NEW/sys/arch/sparc/include/sun_disklabel.h	Thu Jan  1 00:00:00 1970
@@ -88,7 +88,17 @@

 struct sun_disklabel {			/* total size = 512 bytes */
 	char	sl_text[128];
-	char	sl_xxx1[292];
+#if MAXPARTITIONS > 8
+#define SUNXPART (MAXPARTITIONS-8)
+	u_long  sl_xpsum;		/* additive cksum, [sl_xpmag,sl_xxx1) */
+	u_long  sl_xpmag;		/* "extended" magic number */
+#define SL_XPMAG (0x199d1fe2+SUNXPART)
+	struct sun_dkpart sl_xpart[SUNXPART];	/* "extended" partitions, i through p */
+	char	sl_xxx1[292-8-(8*SUNXPART)]; /* [292] including sl_x* */
+#else
+#define SUNXPART 0
+	char    sl_xxx1[292];
+#endif
 	u_short sl_rpm;			/* rotational speed */
 	u_short	sl_pcylinders;		/* number of physical cyls */
 	u_short sl_sparespercyl;	/* spare sectors per cylinder */

--- OLD/sys/arch/sparc/sparc/disksubr.c	Thu Jan  1 00:00:00 1970
+++ NEW/sys/arch/sparc/sparc/disksubr.c	Thu Jan  1 00:00:00 1970
@@ -285,14 +285,16 @@
 #define dkpart(dev) (minor(dev) & 7)

 	struct partition *p = lp->d_partitions + dkpart(bp->b_dev);
-	int labelsect = lp->d_partitions[0].p_offset;
 	int maxsz = p->p_size;
 	int sz = (bp->b_bcount + DEV_BSIZE - 1) >> DEV_BSHIFT;

 	/* overwriting disk label ? */
 	/* XXX should also protect bootstrap in first 8K */
-	if (bp->b_blkno + p->p_offset <= LABELSECTOR + labelsect &&
-	    (bp->b_flags & B_READ) == 0 && wlabel == 0) {
+	/* XXX this assumes everything <=LABELSECTOR is label! */
+	/*     But since LABELSECTOR is 0, that's ok for now. */
+	if ( (bp->b_blkno + p->p_offset <= LABELSECTOR) &&
+	     ((bp->b_flags & B_READ) == 0) &&
+	     (wlabel == 0) ) {
 		bp->b_error = EROFS;
 		goto bad;
 	}
@@ -330,7 +332,7 @@

 /* What partition types to assume for Sun disklabels: */
 static u_char
-sun_fstypes[8] = {
+sun_fstypes[16] = {
 	FS_BSDFFS,	/* a */
 	FS_SWAP,	/* b */
 	FS_OTHER,	/* c - whole disk */
@@ -339,8 +341,31 @@
 	FS_BSDFFS,	/* f */
 	FS_BSDFFS,	/* g */
 	FS_BSDFFS,	/* h */
+	FS_BSDFFS,	/* i */
+	FS_BSDFFS,	/* j */
+	FS_BSDFFS,	/* k */
+	FS_BSDFFS,	/* l */
+	FS_BSDFFS,	/* m */
+	FS_BSDFFS,	/* n */
+	FS_BSDFFS,	/* o */
+	FS_BSDFFS,	/* p */
 };

+/* Given a struct sun_disklabel, assume it has an extended partition
+   table and compute the correct value for sl_xpsum. */
+static u_long sun_extended_sum(struct sun_disklabel *sl)
+{
+ u_long lsum;
+ u_long *xp;
+ u_long *ep;
+
+ xp = (u_long *) &sl->sl_xpmag;
+ ep = (u_long *) &sl->sl_xxx1[0];
+ lsum = 0;
+ for (;xp<ep;xp++) lsum += *xp;
+ return(lsum);
+}
+
 /*
  * Given a SunOS disk label, set lp to a BSD disk label.
  * Returns NULL on success, else an error string.
@@ -388,7 +413,7 @@
 	lp->d_rpm          = sl->sl_rpm;
 	lp->d_interleave   = sl->sl_interleave;

-	lp->d_npartitions = 8;
+	lp->d_npartitions = MAXPARTITIONS;
 	/* These are as defined in <ufs/ffs/fs.h> */
 	lp->d_bbsize = 8192;	/* XXX */
 	lp->d_sbsize = 8192;	/* XXX */
@@ -414,6 +439,43 @@
 		}
 	}

+#if SUNXPART > 0
+
+	/* Clear "extended" partition info, tentatively */
+	for (i=0;i<SUNXPART;i++) {
+		npp = &lp->d_partitions[i+8];
+		npp->p_offset = 0;
+		npp->p_size = 0;
+		npp->p_fstype = FS_UNUSED;
+	}
+
+	/* Check to see if there's an "extended" partition table */
+	if (sl->sl_xpmag == SL_XPMAG) { /* probably... */
+		if (sun_extended_sum(sl) == sl->sl_xpsum) { /* ...yes! */
+			/* There is.  Copy over the "extended" partitions.
+			   This code parallels the loop for partitions a-h. */
+			/* XXX Abstract the common code? */
+			for (i=0;i<SUNXPART;i++) {
+				spp = &sl->sl_xpart[i];
+				npp = &lp->d_partitions[i+8];
+				npp->p_offset = spp->sdkp_cyloffset * secpercyl;
+				npp->p_size = spp->sdkp_nsectors;
+				if (npp->p_size == 0) {
+					npp->p_fstype = FS_UNUSED;
+				} else {
+					npp->p_fstype = sun_fstypes[i+8];
+					if (npp->p_fstype == FS_BSDFFS) {
+						npp->p_fsize = 1024;
+						npp->p_frag = 8;
+						npp->p_cpg = 16;
+					}
+				}
+			}
+		}
+	}
+
+#endif /* if SUNXPART > 0 */
+
 	lp->d_checksum = 0;
 	lp->d_checksum = dkcksum(lp);
 	return (NULL);
@@ -463,6 +525,39 @@
 		spp->sdkp_nsectors = npp->p_size;
 	}
 	sl->sl_magic = SUN_DKMAGIC;
+
+#if SUNXPART > 0
+
+	/* The reason we load the extended table stuff only conditionally
+	   is so that a label that doesn't need it will have NULs there, like
+	   a "traditional" Sun label.  Since Suns seem to ignore everything
+	   between sl_text and sl_rpm, this probably doesn't matter, but it
+	   certainly doesn't hurt anything and it's easy to do. */
+
+	/* Do we need to load the extended table? */
+	for (i=0;i<SUNXPART;i++) {
+		if (lp->d_partitions[i+8].p_offset || lp->d_partitions[i+8].p_size) break;
+	}
+	if (i < SUNXPART) { /* we do */
+		sl->sl_xpmag = SL_XPMAG;
+		for (i=0;i<SUNXPART;i++) {
+			spp = &sl->sl_xpart[i];
+			npp = &lp->d_partitions[i+8];
+			if (npp->p_offset % secpercyl) return(EINVAL);
+			sl->sl_xpart[i].sdkp_cyloffset = npp->p_offset / secpercyl;
+			sl->sl_xpart[i].sdkp_nsectors = npp->p_size;
+		}
+		sl->sl_xpsum = sun_extended_sum(sl);
+	} else {
+		sl->sl_xpmag = 0;
+		for (i=0;i<SUNXPART;i++) {
+			sl->sl_xpart[i].sdkp_cyloffset = 0;
+			sl->sl_xpart[i].sdkp_nsectors = 0;
+		}
+		sl->sl_xpsum = 0;
+	}
+
+#endif /* if SUNXPART > 0 */

 	/* Correct the XOR check. */
 	sp1 = (u_short *)sl;

					der Mouse

			    mouse@collatz.mcrcim.mcgill.edu
		    01 EE 31 F6 BB 0C 34 36  00 F3 7C 5A C1 A0 67 1D
>Release-Note:
>Audit-Trail:

From: der Mouse <mouse@Collatz.McRCIM.McGill.EDU>
To: gnats-bugs@NetBSD.ORG
Cc: netbsd-bugs@NetBSD.ORG
Subject: Re: kern/2675: [dM] 8 partitions is awfully few
Date: Mon, 5 Aug 1996 16:28:07 -0400

 > Synopsis:       [dM] 8 partitions is awfully few

 > --- OLD/sys/arch/sparc/sparc/disksubr.c	Thu Jan  1 00:00:00 1970
 > +++ NEW/sys/arch/sparc/sparc/disksubr.c	Thu Jan  1 00:00:00 1970
 > @@ -285,14 +285,16 @@
 >  #define dkpart(dev) (minor(dev) & 7)
 >  
 >  	struct partition *p = lp->d_partitions + dkpart(bp->b_dev);
 > -	int labelsect = lp->d_partitions[0].p_offset;
 >  	int maxsz = p->p_size;

 Duh.  Fix that up to read

 #define dkpart(dev) (((unsigned int)minor(dev)) % MAXPARTITIONS)

 which is probably what it should have been anyway.

 					der Mouse

 			    mouse@collatz.mcrcim.mcgill.edu
 		    01 EE 31 F6 BB 0C 34 36  00 F3 7C 5A C1 A0 67 1D
State-Changed-From-To: open->feedback 
State-Changed-By: jdolecek 
State-Changed-When: Fri Jun 29 03:57:41 PDT 2001 
State-Changed-Why:  
Ports are being switched to higher number of partitions. Is this 
still a problem for you? 

From: Jaromír Dolecek <jdolecek@netbsd.org>
To: der Mouse <mouse@Rodents.Montreal.QC.CA>
Cc: gnats-bugs@netbsd.org
Subject: Re: kern/2675
Date: Fri, 6 Jul 2001 14:39:07 +0200 (CEST)

 der Mouse wrote:
 > The limit is still an _issue_ for me.  It hasn't been a _problem_ for
 > me since approximately the time I sent the PR; the fixes have been in
 > my private patch tree for a long time.

 Maybe, if you'd make necessary patches to make the change for sparc similar
 way this was handled on i386 and submit the patch via the gnats to this
 PR, the issue could be solved for you and rest of sparc users as well.

 Jaromir
 -- 
 Jaromir Dolecek <jdolecek@NetBSD.org>      http://www.ics.muni.cz/~dolecek/
 NetBSD - just plain best OS! -=*=- Got spare MCA cards or docs? Hand me them!

From: Jaromír Dolecek <jdolecek@netbsd.org>
To: der Mouse <mouse@Rodents.Montreal.QC.CA>
Cc: gnats-bugs@netbsd.org
Subject: Re: kern/2675
Date: Sun, 15 Jul 2001 16:26:15 +0200 (CEST)

 der Mouse wrote:
 > I don't see how it isn't _already_ "solved for [me] and [the] rest of
 > [the] sparc users" (or at least those who care to bother)...is there
 > something wrong with the patches I provided?  They sure work for me.

 Well, I don't know whether they are good or wrong (haven't looked
 on them in that much detail), but since the i386 solution has already
 went through quite big discussion and was found out as acceptable,
 I'd be reluctant to use different thing for other ports.
 Unless the solution would be clearly superiour of course :)

 Jaromir
 -- 
 Jaromir Dolecek <jdolecek@NetBSD.org>      http://www.ics.muni.cz/~dolecek/
 NetBSD - just plain best OS! -=*=- Got spare MCA cards or docs? Hand me them!

From: der Mouse  <mouse@Rodents.Montreal.QC.CA>
To: Jaromír Dolecek <jdolecek@netbsd.org>
Cc: gnats-bugs@netbsd.org
Subject: Re: kern/2675
Date: Sat, 6 Oct 2001 15:36:41 -0400 (EDT)

 >> I don't see how it isn't _already_ "solved for [me] and [the] rest
 >> of [the] sparc users" (or at least those who care to bother)...is
 >> there something wrong with the patches I provided?  They sure work
 >> for me.

 > Well, I don't know whether they are good or wrong (haven't looked on
 > them in that much detail), but since the i386 solution has already
 > went through quite big discussion and was found out as acceptable,
 > I'd be reluctant to use different thing for other ports.

 Well, of *course* the i386 solution is best for all the other ports!
 Let's port fdisk immediately!

 More seriously, what *is* the i386 solution?  As of my freeze point,
 the i386 port is still at MAXPARTITIONS=8.

 Not that it matters, I suppose.  I've seen no evidence anyone is in
 favor of what I suggested; most people couldn't give a damn and the few
 that have responded seem opposed.  (Like almost everything else I've
 tried to do for NetBSD.)  So there's probably no point in keeping the
 PR open.

 /~\ The ASCII				der Mouse
 \ / Ribbon Campaign
  X  Against HTML	       mouse@rodents.montreal.qc.ca
 / \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

From: Jaromír Dolecek <jdolecek@netbsd.org>
To: der Mouse <mouse@Rodents.Montreal.QC.CA>
Cc: gnats-bugs@netbsd.org
Subject: Re: kern/2675
Date: Sun, 7 Oct 2001 21:04:18 +0200 (CEST)

 der Mouse wrote:
 > Well, of *course* the i386 solution is best for all the other ports!
 > Let's port fdisk immediately!

 Nono. It's just that that I'm reluctant to use something different
 if solution on one arch is good and suitable for other archs too.

 > More seriously, what *is* the i386 solution?  As of my freeze point,
 > the i386 port is still at MAXPARTITIONS=8.

 See <i386/disklabel.h>. The i386 solution is to use 'big' minors for
 partitions >8. Seems quite simple, does the job and maintains
 backward compatibility well. I think it could be adopted by
 other archs with only minor efford.

 > Not that it matters, I suppose.  I've seen no evidence anyone is in
 > favor of what I suggested; most people couldn't give a damn and the few
 > that have responded seem opposed.  (Like almost everything else I've
 > tried to do for NetBSD.)  So there's probably no point in keeping the
 > PR open.

 Well, there is - sparc still has MAXPARTITIONS=8 :)

 Jaromir
 -- 
 Jaromir Dolecek <jdolecek@NetBSD.org>      http://www.ics.muni.cz/~dolecek/
 NetBSD - just plain best OS! -=*=- Got spare MCA cards or docs? Hand me them!

From: der Mouse <mouse@Rodents.Montreal.QC.CA>
To: jdolecek@netbsd.org
Cc: gnats-bugs@netbsd.org
Subject: Re: kern/2675
Date: Sat, 5 Jan 2002 15:38:44 -0500 (EST)

 > See <i386/disklabel.h>.  The i386 solution is to use 'big' minors for
 > partitions >8.  Seems quite simple, does the job and maintains
 > backward compatibility well.

 Oh, that's a solution to only the minor-numbering issue; it's got
 nothing to do with the rest of it, such as on-disk labels.

 I think it's really ugly (not to mention comparatively expensive,
 though I suppose converting between minor number and <unit,part> pairs
 doesn't happen all that often).  Having the mapping between <unit,part>
 pairs and minor numbers be that grossly nonlinear for all future time
 seems worse, to me, than one flag day in /dev.  That way lies a system
 that's little but an accretion of scar tissue upon scar tissue as each
 new feature doesn't dare break backward compatability in the slightest.

 But if that's is the way NetBSD has decided It Shall Be, to the point
 of refusing a working, burnt-in addressing of the issue that takes a
 different tack, then I guess it's that or nothing.  So far it's been
 nothing, and since it appears SPARC users are content with that, and
 the issue is a non-problem for me, it's no skin off my nose either way.

 I don't think it affects what I wrote except for the definition of
 dkpart() in disksubr.c (see the addon I sent just after the patches)
 and the corresponding MAKEDEV changes.

 /~\ The ASCII				der Mouse
 \ / Ribbon Campaign
  X  Against HTML	       mouse@rodents.montreal.qc.ca
 / \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B
State-Changed-From-To: feedback->open 
State-Changed-By: fair 
State-Changed-When: Sun Jan 6 14:28:34 PST 2002 
State-Changed-Why:  
Feedback has been provided, and we should answer it properly. 

From: der Mouse <mouse@Rodents.Montreal.QC.CA>
To: gnats-bugs@netbsd.org
Cc:  
Subject: Re: kern/2675
Date: Sun, 6 Jan 2002 19:21:30 -0500 (EST)

 > Feedback has been provided, and we should answer it properly.

 Arguably, I'm also the one who should be answering it, as I'm
 theoretically here as a PR cruncher.  But ISTM there is insufficient
 consensus that any part of the patchset in the PR is a Right enough
 Thing to commit. :-)

 In particular, ISTR seeing it said that /sparc -current hides a
 full-blown native NetBSD disklabel in the spare space I put the
 extended partitions in.  If this is true (it could be just confused
 memory), there is insufficient room to expand it to 16 partitions.  (By
 my count, an N-partition NetBSD disklabel occupies 148+(16*N) bytes.
 This means that the most partitions that can be fit into that 292-byte
 unused area by this method is 9.  By contrast, there's space for 35
 "extended" partitions, 43 total, the way I did it (and four bytes left
 over) - but those partitions have Sun-disklabel constraints.  This is
 more than MAXMAXPARTITIONS, but given the reason MAXMAXPARTITIONS is as
 low as it is, it's not clear that its limit should apply to a port that
 doesn't always have a full-blown NetBSD disklabel on-disk.  What, if
 anything, is MAXMAXPARTITIONS used for, anyway?)

 At any rate, if the decision is to go with a relatively high partition
 count by extending the Sun label, my patches may at least be a useful
 starting point.  (But more likely from historical evidence, I'd say, is
 that people will argue about what the right thing is and end up doing
 nothing because the argument is never settled.  Sigh.)

 /~\ The ASCII				der Mouse
 \ / Ribbon Campaign
  X  Against HTML	       mouse@rodents.montreal.qc.ca
 / \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

From: matthew green <mrg@eterna.com.au>
To: gnats-bugs@netbsd.org
Cc:  
Subject: re: kern/2675
Date: Sat, 03 Apr 2004 02:49:22 +1000

 BTW, when fixing this problem for sparc one should be aware of PR#20277.
State-Changed-From-To: open->closed 
State-Changed-By: mycroft 
State-Changed-When: Tue Jul 6 06:17:38 UTC 2004 
State-Changed-Why:  
This was increased to 16 a long time ago. 
Responsible-Changed-From-To: kern-bug-people->port-sparc-maintainer
Responsible-Changed-By: jnemeth@netbsd.org
Responsible-Changed-When: Wed, 19 Jul 2006 02:59:14 +0000
Responsible-Changed-Why:
This is sparc specific.


State-Changed-From-To: closed->open
State-Changed-By: jnemeth@netbsd.org
State-Changed-When: Wed, 19 Jul 2006 02:59:14 +0000
State-Changed-Why:
The problem has only been solved for i386/amd64 and not generally.


State-Changed-From-To: open->feedback
State-Changed-By: dholland@NetBSD.org
State-Changed-When: Mon, 09 Feb 2015 02:10:38 +0000
State-Changed-Why:
are GPT tables an adequate solution?


State-Changed-From-To: feedback->open
State-Changed-By: dholland@NetBSD.org
State-Changed-When: Mon, 09 Feb 2015 09:11:58 +0000
State-Changed-Why:
Not for boot disks.


>Unformatted:

Home	PR Database Search