disk partitioning

[Alan P. Sexton]

My own setup is 4 eagles and an rm05 on a SI 9900 on a vax 785 running
4.2BSD. We have sources but the following can be done without if you
are not afraid to use adb on the kernel (I've done it on a uvaxII without
sources but it is somewhat different as the MSCP stuff changes things
(especially some of the following arguements)).

Steve Burinsky writes <3496 at brl-smoke.ARPA>:
> 1.  Under 4.2, are there advantages/disadvantages to one large file system
> versus many smaller file systems?  What about quotas and file system
> efficiency?  My understanding is that small file systems are a relic
> of 16-bit machines which could only handle 64k inodes per file system.

The 4.2 fast file system attempts to keep individual files in single cylinder
groups so that in a large file system the file blocks shouldn't spread very
much over the whole system (thus large file systems (LFS) not a disadvantage).
LFS take longer to back up and I prefer to do backups in smaller stages
(if something goes wrong in backing up 2 small file systems there is
a 50% probability that you only have to redo the backup for one of them)
The quota system is an efficiency overhead itself -  with smaller file systems
you may be able to put logical groups of users onto their own partitions and
so do away with quotas (Group A has 100 Mb to share between themselves - they
can work without their space being affected by any other groups and can manage
their own space among themselves - This has turned out to be much more
flexible than quotas for us while still remaining reasonably fair.
A disadvantage of many small file systems is that there
is a maximum of 16 FS's mountable at any one time (This however is easily
fixed if you have sources - look in the Building Systems with Config paper
in the section on Data Structure Sizing Rules). Naturally the feasibility
of the above (and following) suggestions depends very much on your environment.

> 2.  If I use the "c" partition, how do I account for/leave enough space for
> the bad sector information and replacement sectors?

On my system (admittedly a System Industries driver but I believe it is
the same for standard 4.2) the bad block table is on the last track. To
be precise there is a copy of the table on every even numbered sector on the
last track of the last cylinder of each disk. The replacement blocks then
stretch backwards (on an eagle taking up another 2 and a bit tracks, on an
rm05 taking up an extra 4 tracks). I suggest rounding up to the nearest
track. Thus total bad block overhead on an eagle is the last 4 tracks
and on an rm05 is the last 5 tracks on the last cylinder of the disk.

> 3.  If I resize the partitions, how do I account for/leave enough space for
> the bad sector information and replacement sectors?

The c partition should cover the whole disk INCLUDING the bad block data
at the end of the disk. As for the rest - in your driver there is a table
called disktype_sizes (where disktype is the name of your type of disk).
this contains the length of each disk partion in sectors and the number
of the first cylinder of that disk partition on the disk (all disk partitions
start on a cylinder boundary). Simply change these values to whatever is
desired but just have no partition (except c) cover the bad block data.
Note 1. /etc/disktab should be changed accordingly.
Note 2. Remember that your new kernel may not be able to read your old
	data if you change the current partition set up
Note 3. Don't decrease the size of the a partition as you might not
	then be able to boot new 4.n unices from tape without zapping
	all your data.
Note 4. Don't forget to use the new tables in the boot stuff (/sys/stand)
	as your old standalone programs will still only recognise
	the old disk partitions.
> 
> 4.  This may be a silly question, but I can't figure it out.  The background
> info above says that you can access the bad sector information and 
> replacement sectors only through the "c" partition.  Well, if I do a disk-
> to-disk copy using the "c" partition, am I copying one disk's bad sectors and
> bad sector information to the other disk?!
> 
Not at all a silly question!!! when doing a c partition to c partition copy
you must specify the size of the transfer (I presume you are using dd) so that
it DOES NOT include the bad block data. To be safe you could define some
partition to be the whole disk EXCEPT the bad block data and use that for disk
to disk transfers. In particular, aside from the data loss, if you zap the bad
block table it is not easy to get it back unless you have a printout of what
blocks were in it. You may have to use an extensive disk tester (painful) with
(in my case) the error recovery mechanism on the disk controller switched
off (call in the technician) and still not find a quarter of the bad blocks.

On my system I have made major disk reorganisation changes and have been
running with them for several months now without problems. The relevant
tables from the disk driver is as follows:

	/* alan's changes: 30 cyl on rm05 == 19 cyl on eagle = 1 segment
	so root(a) = 2 segs, data = 12 seg (e&f) or 24 seg (d). g partition is
	what is left of last cylinder when bb table ( = 1 track) and replacement	blocks ( = 4 tracks are removed). This partition should hold *RAW* info
	for backups. swap part (b) = 13Mb = 1.4 segs to take up leftover space
	h is the whole disk except for the bb stuff. */
   rm05_sizes[8] = {
	36480,    0,            /* A=cyl   0 thru 59  =  60 cyl */
	25536,   60,            /* B=cyl  60 thru 101 =  42 cyl */
	500384,   0,            /* C=cyl   0 thru 822 = 823 cyl */
	437760, 102,            /* D=cyl 102 thru 821 = 720 cyl */
	218880, 102,            /* E=cyl 102 thru 461 = 360 cyl */
	218880, 462,            /* F=cyl 462 thru 821 = 360 cyl */
	448,    822,            /* G=cyl 822 thru 822 =   1 cyl - BB stuff */
	499776,   0,            /* H=cyl   0 thru 821 = 822 cyl */
},

	/* alan's changes: 30 cyl on rm05 == 19 cyl on eagle = 1 segment
	so root(a) = 2 segs, data = 12 seg (e&f) or 24 seg (d) plus 12 seg (h). 
	g partition is what is left of last cylinder when bb table ( = 1 track)
	and replacement	blocks ( = 3 tracks are removed) plus 5 leftover
	cylinders. Swap part (b) = 6 segs (== 56Mb) (NB this is half a data
	partition so if a special filesystem is required this can be used
	and backed up easily)						*/
   eagle_sizes[8] = {
	36480,  0,              /* A=cyl   0 thru  37 =  38 cyl */
	109440, 38,             /* B=cyl  38 thru 151 = 114 cyl */
	808320, 0,              /* C=cyl   0 thru 841 = 842 cyl */
	437760, 152,            /* D=cyl 152 thru 607 = 456 cyl */
	218880, 152,            /* E=cyl 152 thru 379 = 228 cyl */
	218880, 380,            /* F=cyl 380 thru 607 = 228 cyl */
	5584,   836,            /* G=cyl 836 thru 841 =   6 cyl - BB stuff */
	218880, 608,            /* H=cyl 608 thru 835 = 228 cyl */
},

Note that I increased the a partition size as we do some work on kernels
and needed more space in root (we also needed a larger /tmp)
Note also that I increased the partition sizes to an integral number of tracks
- I see no reason to waste that space.

If anyone has any questions, comments or criticisms or knows of something I
missed or forgot to mention I would be delighted to hear about it. In particular
if anyone knows of a good reason to keep the sizes at the defaults I'd like
to hear it (NB so that people can swap disks is NOT, in my opinion, a good
reason as this can easily be done by creating a filesystem (excluding the
BB data) on a full c partition. Unix will understand the filesystem on
another machine and won't overwrite the bad block data unless you specifically
try to do so).

> You are to be congratulated for reading this rather lengthy message.
ditto re the reply

Alan P. Sexton				Systems Programmer
alan%ecrcvax.UUCP at Germany.CSNET		European Computer-Industry
..!mcvax!unido!ecrcvax!alan		Research Centre GmbH