From owner-freebsd-fs Fri Oct 29 14:51:15 1999 Delivered-To: freebsd-fs@freebsd.org Received: from charon.fmi.com (charon.fmi.com [157.33.227.4]) by hub.freebsd.org (Postfix) with ESMTP id CDB43155B8 for ; Fri, 29 Oct 1999 14:51:01 -0700 (PDT) (envelope-from Brendon_Meyer@fmi.com) Received: from babylon.nola.fmi.com (babylon.nola.fmi.com [157.33.3.49]) by charon.fmi.com (8.9.3/8.9.3) with ESMTP id QAA03204; Fri, 29 Oct 1999 16:50:47 -0500 (CDT) Received: from exsysadm.irja.fcx.com (exsysadm.irja.fcx.com [157.47.15.198]) by babylon.nola.fmi.com (8.6.9/8.6.12) with ESMTP id QAA01201; Fri, 29 Oct 1999 16:50:41 -0500 Received: from fmi.com (localhost [127.0.0.1]) by exsysadm.irja.fcx.com (8.9.3/8.9.3) with ESMTP id HAA03378; Sat, 30 Oct 1999 07:59:24 +1000 (EST) (envelope-from Brendon_Meyer@fmi.com) Message-ID: <381A18BB.48C2F4E0@fmi.com> Date: Sat, 30 Oct 1999 07:59:24 +1000 From: Brendon Meyer X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.3-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Greg Lehey Cc: freebsd-fs@FreeBSD.ORG Subject: Re: Journaling References: <199910280305.VAA13281@panzer.kdm.org> <19991028085348.39481@mojave.worldwide.lemis.com> Content-Type: multipart/alternative; boundary="------------05EC013FE31FB7BB9593D362" Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org --------------05EC013FE31FB7BB9593D362 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Greg Lehey wrote: > On Wednesday, 27 October 1999 at 21:05:04 -0600, Kenneth D. Merry wrote: > > Don wrote... > >>> Actually, it's technically 8 partitions, a-h, but c is "special", and > >>> shouldn't normally be used. > >> Correct C represents the entire disk. > >> > >>> This is a disklabel limitation, not a filesystem limitation. I believe > >>> that Solaris x86 may be able to do 16 partitions (or so a guy at Sun told > >>> me). > >> > >> I will have to check this out. Thanks for the info. Is there any reason > >> that disklabel has this limit? > > > > It has been that way for a long time. I'm not sure why the limit is 8, but > > it is. (Someone might know. I suspect it was just an arbitrary value > > chosen a long time ago.) Changing it might break backwards compatibility, > > though. > > There was some discussion about increasing it at one point. But as > you say, it would probably confuse some programs, and I personally > don't see any need. Ok this is really starting to get off topic on the point of the original thread but I would like to make a comment though. While I agree that expanding the current disklabel may break some existing stuff, I do beg to disagree about the need (this is an opinion so take it with the appropriate grain of salt). There are two situations where you can quite easily 'run out' of partitions. 1. Physically large individual data volumes. Example is a DPT RAID configuration of a 4 x 32 GB disk RAID 5 array which then presents the resultant RAID 5 disk array to the system as an individual 96 GB drive. 2. System disk with more than 1 'DOS' style partition already in use (example: DOS/95/98 + BSD + LINUX). With individually large data volumes the 'sting' is somewhat reduce by the judicious use of FDISK slices, but it is not removed entirely. With most servers having individual volumes <60Gb this scheme generally works reasonable well but I can tell you from personal experience that when you have a 4 x 32 GB volume (as above) which you do need to split up further, then this does become a bit of a problem. In the case of a 'shared system disk', often you don't have the option to use any additional 'FDISK' style slices as they have already all been used by other OS's. Cheers, -- Brendon Meyer (Brendon_Meyer@fmi.com) PT Mineserve International / PT Freeport Indonesia / Freeport McMoran Timika, Tembagapura, Jakarta, Singapore, Cairns, New Orleans --------------05EC013FE31FB7BB9593D362 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Greg Lehey wrote:
On Wednesday, 27 October 1999 at 21:05:04 -0600, Kenneth D. Merry wrote:
> Don wrote...
>>> Actually, it's technically 8 partitions, a-h, but c is "special", and
>>> shouldn't normally be used.
>> Correct C represents the entire disk.
>>
>>> This is a disklabel limitation, not a filesystem limitation.  I believe
>>> that Solaris x86 may be able to do 16 partitions (or so a guy at Sun told
>>> me).
>>
>> I will have to check this out. Thanks for the info. Is there any reason
>> that disklabel has this limit?
>
> It has been that way for a long time.  I'm not sure why the limit is 8, but
> it is.  (Someone might know.  I suspect it was just an arbitrary value
> chosen a long time ago.)  Changing it might break backwards compatibility,
> though.

There was some discussion about increasing it at one point.  But as
you say, it would probably confuse some programs, and I personally
don't see any need.


Ok this is really starting to get off topic on the point of the original thread but I would like to make a comment though.

While I agree that expanding the current disklabel may break some existing stuff, I do beg to disagree about the need (this is an opinion so take it with the appropriate grain of salt).

There are two situations where you can quite easily 'run out' of partitions.
1.  Physically large individual data volumes.  Example is a DPT RAID configuration of a 4 x 32 GB disk RAID 5 array which then presents the resultant RAID 5 disk array to the system as an individual 96 GB drive.
2.  System disk with more than 1 'DOS' style partition already in use (example: DOS/95/98 + BSD + LINUX).

With individually large data volumes the 'sting' is somewhat reduce by the judicious use of FDISK slices, but it is not removed entirely.  With most servers having individual volumes <60Gb this scheme generally works reasonable well but I can tell you from personal experience that when you have a 4 x 32 GB volume (as above) which you do need to split up further, then this does become a bit of a problem.

In the case of a 'shared system disk', often you don't have the option to use any additional 'FDISK' style slices as they have already all been used by other OS's.
 

Cheers,
  

-- 
Brendon Meyer
(Brendon_Meyer@fmi.com)
PT Mineserve International / PT Freeport Indonesia / Freeport McMoran
Timika, Tembagapura, Jakarta, Singapore, Cairns, New Orleans
  --------------05EC013FE31FB7BB9593D362-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message