NetNews Usenet Archive 1993 #1/NN_1993_1.iso/spool/comp/unix/ultrix/9212

Internet Message Format | 1993-01-08 | 5.7 KB

Xref: sparky comp.unix.ultrix:9212 comp.unix.misc:4876
Newsgroups: comp.unix.ultrix,comp.unix.misc
Path: sparky!uunet!haven.umd.edu!decuac!pa.dec.com!nntpd2.cxo.dec.com!nabeth!alan
From: [e-mail] (Alan Rollow - Alan's Home for Wayward Tumbleweeds.)
Subject: Re: partition & filesystem mysteries
Message-ID: <[e-mail]>
Lines: 111
Sender: alan@nabeth (Alan Rollow - Alan's Home for Wayward Tumbleweeds.)
Reply-To: [e-mail] (Alan Rollow - Alan's Home for Wayward Tumbleweeds.)
Organization: Digital Equipment Corporation
References:  <[e-mail]>
Date: Thu, 7 Jan 1993 23:08:15 GMT


In article <[e-mail]>, [e-mail] (Jurgen Botz) writes:
>
>I am somewhat mystified by the process of changing disk partitions
>under Ultrix (4.x).  In "The Unix System Administration Handbook"
>(Evi & Nemeth) it states that BSD systems must have partition
>boundaries aligned with cylinders (or even cylinder groups?) or
>take a serious performance penalty.

I believe this belief dates from a time when the cylinder to cylinder
seek time of disks was very much slower than the head switch time
or even rotational latency.  Since the file system liked to lay
things out on cylinder boundries for cylinder groups, bad alignment
would tend to run things over cylinder boundries and incur these
(probably) expensive seeks.

Today you have disks that, at best, put extra sectors at the end of
tracks, have a different number of cylinders depending on where
you are on the disk, have controllers that think they are smarter than
you are about what order I/O should be done, read caches that read
a couple of tracks of you anyway and sometimes write caches that
hold onto the data until a good time write it.

On today's disks you have little way of telling where the cylinder
boundries really, assuming it matters.  I doubt that strict attention
to supposed cylinder alignment will make much difference today.  It
would be easy enough to test if it did.

>Is this also true for Ultrix
>(which is derived from 4.2BSD) or does the Ultrix automatically
>align partitions on cylinder boundaries?

ULTRIX uses a variety of methods for laying out partitions table,
depending on how long the disk has been available, size conventions
for interesting file systems and a bit of folklore.  About the
only constant through all the disks is that 16 KB is allocated
for the A partition (a typical root file system place).  One of
a set of sizes will be used for page/swap space.  Older disks may
have inherited partition tables, middle aged disks have a strange
mix of partition tables that seems to follow little rhyme nor reason
and new disks follow the guidelines in the V4.2A disktab file.

>When I make a new file-
>system on a partition I created it tells me that "n sectors in the
>last cylinder are not allocated".  The manual pages say nothing
>about this, and give no advice on how to calculate partition
>sizes.
>
>I tried figuring out the secret formula from the disk geometry and
>the default partitions in /etc/disktab, but didn't get very far.
>The default partition sizes are /not/ an even multiple of the number
>of sectors/cylinder.  I also can't find any reasonable function that
>woud seem to determine the difference... so, what gives?  There
>obviously has to be some formula based on the disk geometry, but
>I can't find it documented anywhere and I've looked everywhere I
>know to look...

Very few, if any, of the supported disks use the disk geometry to
determine partition setup.  While the sizes are sometime chosen
in ways that clearly don't consider how the file system uses the
space (D, E and F of the RZ56), there is a preference to consider
the partition size over other things.  The A partition is sized to
hold a typical root file system.  The B partition is chosen to provide
sufficient page/swap for typical memory configuration of the most
common systems.  The G partition is usually sized to hold most of
/usr.  Whatever is left over goes to H.

Also keep in mind that cylinder alignment will almost never sync
up with the sizes that the file system uses.  Consider a typical
file system with an 8 KB block size.  To waste the least amount
of space you'd want the file system size to be a multiple of 8 KB.
You'd also like the size to be such that you have 16 cylinders in each
cylinder group.  Too little space in the last one and you may not
enough space for the inodes.

If you manage to keep exactly 16 cylinders in each group, then the
8 KB multiple falls out.  But then you're likely to have some space
at the end of the disk that may be enough to be interesting but too
small to be useful.  You're also going to have many different partition
sizes.

Consider three different disks; an RA90, ESE20 and RZ57 where you want
a perfectly aligned root file system that is at least 16 KB.  The cylinder
size and cylinder group size (at 16cyl/group) of the three disks is:

    RA90  - 897   - 14,352 sectors.
    ESE20 - 512   -  8,192 sectors.
    RZ57  - 1,065 - 17,040 sectors.

The ESE20 is going to be nice to us, since we can get exactly 16 KB
using 4 cylinder groups.  The RZ57 will only need to two cylinder
groups to get at least 16 KB and the RA90 will need 3 with plenty
of space left over.

Keeping track of many disks each with a different set of partition
sizes is not how I'd want to spend an interesting amount of my
time as system manager.  Especially when there may be little value.

Personally I'd concentrate on getting the best use of the space
and not worry about geometries.  If you have disk where it makes
a significant performance difference, then it be worth the effort,
but otherwise, not.

>
>--
>Jurgen Botz, [e-mail]
>Northampton, MA, USA
>
--
Alan Rollow                [e-mail]