Date: Sat, 30 Oct 1999 07:59:24 +1000 From: Brendon Meyer <Brendon_Meyer@fmi.com> To: Greg Lehey <grog@lemis.com> Cc: freebsd-fs@FreeBSD.ORG Subject: Re: Journaling Message-ID: <381A18BB.48C2F4E0@fmi.com> References: <Pine.BSF.4.05.9910272146010.36049-100000@calis.blacksun.org> <199910280305.VAA13281@panzer.kdm.org> <19991028085348.39481@mojave.worldwide.lemis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--------------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 <!doctype html public "-//w3c//dtd html 4.0 transitional//en"> <html> Greg Lehey wrote: <blockquote TYPE=CITE>On Wednesday, 27 October 1999 at 21:05:04 -0600, Kenneth D. Merry wrote: <br>> Don wrote... <br>>>> Actually, it's technically 8 partitions, a-h, but c is "special", and <br>>>> shouldn't normally be used. <br>>> Correct C represents the entire disk. <br>>> <br>>>> This is a disklabel limitation, not a filesystem limitation. I believe <br>>>> that Solaris x86 may be able to do 16 partitions (or so a guy at Sun told <br>>>> me). <br>>> <br>>> I will have to check this out. Thanks for the info. Is there any reason <br>>> that disklabel has this limit? <br>> <br>> It has been that way for a long time. I'm not sure why the limit is 8, but <br>> it is. (Someone might know. I suspect it was just an arbitrary value <br>> chosen a long time ago.) Changing it might break backwards compatibility, <br>> though. <p>There was some discussion about increasing it at one point. But as <br>you say, it would probably confuse some programs, and I personally <br>don't see any need.</blockquote> <p><br>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. <p>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). <p>There are two situations where you can quite easily 'run out' of partitions. <br>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. <br>2. System disk with more than 1 'DOS' style partition already in use (example: DOS/95/98 + BSD + LINUX). <p>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. <p>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. <br> <p>Cheers, <br> <pre>-- Brendon Meyer (Brendon_Meyer@fmi.com) PT Mineserve International / PT Freeport Indonesia / Freeport McMoran Timika, Tembagapura, Jakarta, Singapore, Cairns, New Orleans</pre> </html> --------------05EC013FE31FB7BB9593D362-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?381A18BB.48C2F4E0>