pavlov@canisius.UUCP (Greg Pavlov) (11/28/89)
The disktab file on a DECStation 3100 here includes the following in a comment at the top of the file: "...all disks have no defaults for the 'h' partition. The strategy here is that 'a' always has the same amount for all disks. The 'b' partition is four times 'a' while 'c' is always the entire disk. The sum of 'd','e', and 'f' is equal to 'g' which is everything else." Ok, we pay attention to the "rule" for the 'c' partition. But none of the rest make any sense to us, at least most of the time. Where does these algo- rithms come from ? What is in ULTRIX that penalizes ignoring them ? greg pavlov, fstrf, amherst, ny
alan@shodha.dec.com ( Alan's Home for Wayward Notes File.) (11/28/89)
In article <2615@canisius.UUCP>, pavlov@canisius.UUCP (Greg Pavlov) writes: > > [ Quoteing from the DECstation 3100 /etc/disktab... ] > > "...all disks have no defaults for the 'h' partition. The strategy here > is that 'a' always has the same amount for all disks. The 'b' partition > is four times 'a' while 'c' is always the entire disk. The sum of 'd','e', > and 'f' is equal to 'g' which is everything else." > > Ok, we pay attention to the "rule" for the 'c' partition. But none of the > rest make any sense to us, at least most of the time. Where does these algo- > rithms come from ? The subset of disks in that disktab is very small being all the SCSI disks we we had available with the DECstation was announced. If you look at the disktab on VAX you will nearly as many different styles of partitioning as there are disks. I would guess that the engineers that setup these partitions tried to get some consistancy. The choice of size for the A partition was probably one which would comfortably fix the root file system for the RISC systems. Making B four times the size of A gives a good safe size for the page and swap. Having G be the rest of the disk and making D, E and F be sub-partitions of G is easy to remember and cal- culate. For the RZ55 at least D, E and F are one third of G. > What is in ULTRIX that penalizes ignoring them ? /etc/disktab is the default. If you don't like the defaults we provide chpt to give the disk it's own partition table and editors so that you can have disktab reflect reality. As long as you live by the restrictions of chpt(8) you probably won't have any problems. The biggest mistake that people make is accidently having two partition overlap or paging over the partition table. If you find a partitioning that works better, go ahead and use it. If you find some real performance benefit from it, let us know. long as you > > greg pavlov, fstrf, amherst, ny -- Alan Rollow alan@nabeth.enet.dec.com
chris@mimsy.umd.edu (Chris Torek) (11/28/89)
In article <2615@canisius.UUCP> pavlov@canisius.UUCP (Greg Pavlov) writes: >Where does these [disk partition size] algorithms come from? Most likely, from the last person to edit the file. >What is in ULTRIX that penalizes ignoring them ? Nothing much. Make sure you leave yourself enough space, but not too much, and make sure you remember you changed them when you change versions (especially major versions), and make sure you can handle the mess when the new version ignores the old (non-default) partition tables.... We always ignore the manufacturer's (DEC's/UCB's/Encore's) `standard' tables and rearrange things to suit us. Then again, we also do things like put control-T in the kernel :-) -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@cs.umd.edu Path: uunet!mimsy!chris
bph@buengc.BU.EDU (Blair P. Houghton) (11/29/89)
In article <2615@canisius.UUCP> pavlov@canisius.UUCP (Greg Pavlov) writes: > > The disktab file on a DECStation 3100 here includes the following in a > comment at the top of the file: [...default partitioning strategy deleted...] > Ok, we pay attention to the "rule" for the 'c' partition. But none of the > rest make any sense to us, at least most of the time. Where does these algo- > rithms come from ? What is in ULTRIX that penalizes ignoring them ? Sounds like some development-policy rule-of-thumb, kindof like the 9-to-1 resistance ratio for biasing a class-A common-emitter bipolar transistor amplifier stage. It seems that, since the size of the 'a', (root) partition is roughly proportional to the size of the system, then the size of the 'b' (default swapping) partition would also be roughly proportional to the size of the 'a' partition. Certainly nothing prevents your changing them to get improved performance in a manner that improves the fulfillment of your particular needs. --Blair "I use the f partition to even out the short leg on my desk, myself..."
envbvs@epb2.lbl.gov (Brian V. Smith) (11/29/89)
In article <5001@buengc.BU.EDU>, bph@buengc.BU.EDU (Blair P. Houghton) writes: < In article <2615@canisius.UUCP> pavlov@canisius.UUCP (Greg Pavlov) writes: < > < > The disktab file on a DECStation 3100 here includes the following in a < > comment at the top of the file: < < [...default partitioning strategy deleted...] < < > Ok, we pay attention to the "rule" for the 'c' partition. But none of the < > rest make any sense to us, at least most of the time. Where does these algo- < > rithms come from ? What is in ULTRIX that penalizes ignoring them ? < < Sounds like some development-policy rule-of-thumb, kindof like the < 9-to-1 resistance ratio for biasing a class-A common-emitter bipolar < transistor amplifier stage. It seems that, since the size of the 'a', < (root) partition is roughly proportional to the size of the system, < then the size of the 'b' (default swapping) partition would also be < roughly proportional to the size of the 'a' partition. < Seems to me like you should set the size of the swap partition to whatever you need in virtual memory. Except to make sure that you have enough space in the g partition for /usr, it seems kind of silly to restrict swap space or waste disk space by having more than one needs just to follow some rule-of-thumb for sizing. _____________________________________ Brian V. Smith (bvsmith@lbl.gov) Lawrence Berkeley Laboratory I don't speak for LBL, these non-opinions are all mine.
saus@media-lab.media.mit.edu (Mark Sausville) (12/02/89)
In article <4306@helios.ee.lbl.gov> envbvs@epb2.lbl.gov (Brian V. Smith) writes:
Path: mit-amt!snorkelwacker!usc!cs.utexas.edu!hellgate.utah.edu!helios.ee.lbl.gov!epb2.lbl.gov!envbvs
From: envbvs@epb2.lbl.gov (Brian V. Smith)
Newsgroups: comp.unix.ultrix
Date: 28 Nov 89 22:05:05 GMT
References: <5001@buengc.BU.EDU> <2615@canisius.UUCP>
Sender: usenet@helios.ee.lbl.gov
Reply-To: envbvs@epb2.lbl.gov (Brian V. Smith)
Organization: lbl
Lines: 31
Seems to me like you should set the size of the swap partition to
whatever you need in virtual memory.
Except to make sure that you have enough space in the g partition for /usr,
it seems kind of silly to restrict swap space or waste disk space by having
more than one needs just to follow some rule-of-thumb for sizing.
_____________________________________
Brian V. Smith (bvsmith@lbl.gov)
Lawrence Berkeley Laboratory
I don't speak for LBL, these non-opinions are all mine.
Which brings up a gripe of mine. Unless your root disk has a swap
partition as large or larger than your physical memory, you can forget
full crash dumps. It won't use your swap space on other disks to
write the dump but merely truncate the dump to the size of the swap
partition on the root disk. Unless I'm wrong. This is nasty because
it's not what you're thinking about when you bring up a new system
(hey, it won't crash, right?).
By the way, speaking of rules of thumb, everyone seems to think that
you ought to have greater that 2 times the physical memory size for
swap space. Anyone have any authoritative knowledge on how this rule
should be modified as physical memory increases. I have 128M in my
machine and only 160M of swap space. This machine has never come
close to running out of swap in over 6 months of hard use (> 64 users,
timesharing, news, mail, editing, light program development, some
image crunching, etc., etc.).
Mark
Mark Sausville MIT Media Laboratory
Computer Systems Administrator Room E15-354
617-253-0325 20 Ames Street
saus@media-lab.media.mit.edu Cambridge, MA 02139