Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!mcvax!unido!ecrcvax!alan From: alan@ecrcvax.UUCP (Alan P. Sexton) Newsgroups: net.unix-wizards Subject: Re: disk partitioning Message-ID: <260@ecrcvax.UUCP> Date: Wed, 10-Sep-86 09:08:27 EDT Article-I.D.: ecrcvax.260 Posted: Wed Sep 10 09:08:27 1986 Date-Received: Wed, 10-Sep-86 20:17:45 EDT References: Reply-To: alan@ecrcvax.UUCP (Alan P. Sexton) Organization: ECRC, D-8000 Muenchen 81, W. Germany Lines: 136 Summary: How to do it (LONG) 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@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@Germany.CSNET European Computer-Industry ..!mcvax!unido!ecrcvax!alan Research Centre GmbH