A few MORE questions about 4.3BSD partitions.

Steve Herber herber at bgsuvax.UUCP
Wed Feb 10 05:56:20 AEST 1988


I spent some time playing with the partition sizes defined in the
uda.c UNIBUS disk driver because we were installing some System Industries
SI83C disk drives (522Mb), DEC RA82 compatible (see a follow up article
in comp.periphs about this installation).  I wanted to stretch out the
useful disk space as much as possible.  I noticed that when I used
/etc/newfs, it usually listed a large number of wasted sectors in the
last cylinder.  I finally figured out that the number of wasted sectors
was equal to the difference between the number of sectors given for
that partition in /etc/disktab and the total number of sectors available
on the number of cylinders used for that partition.  Newfs always
rounded up and wouldn't allow a cylinder to be split between partitions.

Well, I got out my calculator and quickly figured out CYLINDERS NEEDED *
SECTORS/TRACK * TRACKS/CYLINDER so that all of my partitions ended EXACTLY
on cylinder boundaries.  Boy, was I proud of myself (pat myself on back
here:-) for getting the most efficient usage out of my disks...

...until I started to get 'CAN NOT READ BLOCK: BLK 1016197' errors from
FSCK on a few of the partitions where the block number was always 3 from 
the end of the partition.  From that point on, my disk was corrupted
beyond FSCK's ability to repair it.  I eventually figured out that 
I could build the partition using sector sizes 3 smaller the maximum
number available on the cylinder boundaries and I have not had any
corruption since.

OK, now the $64,000 question.  Why can't I make the partition sizes
exactly equal to the maximum of sectors available on a group of
cylinders?  Does there have to be a fixed number of 'padding' sectors
at the end so that the Unix filesystems will be OK?

		...inquiring minds want to know...

Thanks in advance.

-- 

Steve Herber			CSNET herber at bgsu.edu
Sr. Systems Programmer		UUCP  ...!osu-cis!bgsuvax!herber
Bowling Green State Univ.



More information about the Comp.unix.wizards mailing list