expert@lbl-csam.arpa (11/25/85)
Can somebody help me, please? We run a VAX 750 with 4.1bsd and SI disk drives. We are planning on installing a 300Mbyte (pseudo-RM05) drive and I've been looking through hp.c. There seem to be some magic numbers in the "size" structure (partitioning info.) for the drives, which I don't understand. "Size" has two parts: 'daddr_t nblocks' (which turns out to be type 'int') and 'int cyloff'. It appears that 'cyloff' is the cyl. offset to the start of the partition. But where do the numbers for 'nblocks' come from? There are 8 partitions set up in my hp.c: nblocks cyloff comment ------- ------ ------- 15884 0 "A" = cyl 0 thru 26 33440 27 "B" = cyl 27 thru 81 500384 0 "C" = cyl 0 thru 822 15884 562 "D" = cyl 562 thru 588 55936 589 "E" = cyl 589 thru 680 86240 681 "F" = cyl 681 thru 822 158592 562 "G" = cyl 562 thru 822 291346 82 "H" = cyl 82 thru 561 According to my calculations, this means that the number of 'nblocks' per cly. is anywhwere from 588.3 to 608.0. (I can also see that the final partition scheme I use will make a big difference in how much space I can use: Using "A"+"B"+"H"+"D"+"E"+"F" gets 498730 blocks Using "A"+"B"+"H"+"G" gets 499262 blocks Using "C" gets 500384 blocks; I can believe this, due to wasted space in partitioning.) Further, it appears that the numbers to use in /etc/mkfs are 1/2 of the 'nblocks' number (for "size") along with the standard '3 304' (for "m" and "n"). Is this correct? Help, please. Richard Collins (trwspf!expert@lbl-csam)
jsdy@hadron.UUCP (Joseph S. D. Yao) (11/28/85)
In article <46@brl-tgr.ARPA> expert@lbl-csam.arpa writes: > ... There seem to be some magic numbers in the "size" structure >(partitioning info.) for the drives, which I don't understand. Daddr_t is whatever type best holds a disk block address. This must be at least 30 bytes. It should be a long int, but Berkelians tend to think that if a 16-bit machine falls in the woods, no-one will hear it. ;-) You are obviously using a 4BSD system. I will try to remember the correct info for both BSD and USG. For BSD, the root partition is always 15884 sectors ("blocks" is not a good term here, although the code uses it). This is nice and reasonable for an RP0[456]. It is minimal for the others. Being LCD, it is thus the standard. This will usually not completely cover a cylinder on other drives, leading to problems when dd'ing using a multiple of the cylinder size. Partition B, often used as swap, is 33440 sectors long. Partition C is the whole disk. Partition H is the next 291346 (?) sectors, if they are there. Note that, although 4.1 originally set this up to fit exactly onto an RP06, because 4.2 skips the bad-block tables at the end of most HP (DB) drives, this no longer fits an RP06! Anyway, whether or not partition H is taken out, partition G is the rest of the disk. Partitions D, E, and F cover partition G. Partition D is always 15884 sectors, just like partition A. Partition E is next, often (not always) 55936 sectors. And Partition F is the rest of Partition G. This allows you to EITHER use a large partition (G) or three smaller ones (DEF); OR even to use the whole disc as one FS (C). Of course, some sites will munge with the tables and break this standard. And under Ultrix, this can be changed dynamically and written on the disk -- something that a comment in the driver has for a long time said should be done. I like. Some of the munged non-support, I don't like ... in particular, if mkfs can't ioctl-read a partition table, it will write a zero-length partition table onto the drive AND MARK IT VALID -- and then NOTHING can open and access that drive, even to change the partition table! (*sigh*) Anyway, due to "wasted space" in partitioning, don't believe the sizes in the table. The standard sizes always do not cover the partitions (except on the RP0[456]). Believe the entries in /etc/disktab or your disk manual, instead. >Further, it appears that the numbers to use in /etc/mkfs are 1/2 of >the 'nblocks' number (for "size") along with the standard '3 304' (for >"m" and "n"). Is this correct? Berkeley is trying to get people to think in "Kbytes" rather than sectors or blocks. So, yes, this is right. Now for System V. The only real standard seems to be that the root partition is 5000 "blocks", and /usr is ... hmmm, that seems to vary. Anyway, blocks also vary, being either 512 or 1024 bytes, depending on which file system you look at. (But mkfs strongly believes in 1024 bytes.) Partition 7 is the whole disk. Whichever of partitions 1-6 are used seem to start at regular intervals along the disk, or whatever the designer felt reasonable, and a lot of designers felt different ways. Each of partitions 1-7, however, include the whole rest of the disc! This is nice, because then I have a lot of flexibility in how I set up my file systems. This is VERY NASTY, since then I can destroy a later file system by writing into earlier partitions. On my RA60's, I combine partitions 2&3 and 4&5 (6 is empty) into file systems that are (by no coincidence) exactly the size of my RA81's partitions. (You see, I planned this when I wrote the driver. ;-)) BUT, I have to keep this written down somewhere, or I will do something very nasty like creating another file system on partition 3, in the middle of an existing one. I finally just made those partitions inaccessible (either mode 0 or I removed them) (and, yes, root can access mode-0 files -- and WHO LET YOU do everything as root? you should NEVER use root, well, unless you really have to. i have discs owned by bin and mode 400, and everything works REAL nice.). I'm beginning to ramble again, aren't I? Ta. Happy Thanksgiving or Christmas or whenever it is wherever you are. -- Joe Yao hadron!jsdy@seismo.{CSS.GOV,ARPA,UUCP}
friesen@psivax.UUCP (Stanley Friesen) (12/02/85)
In article <100@hadron.UUCP> jsdy@hadron.UUCP (Joseph S. D. Yao) writes: > >Daddr_t is whatever type best holds a disk block address. This >must be at least 30 bytes. ^^^^^ I presume you mean *bits*! > It should be a long int, but Berkelians >tend to think that if a 16-bit machine falls in the woods, no-one >will hear it. No it should be whatever type best holds a disk block number. That is it should be *different* on different machines - that is why it is a *typedef*. Anyone who ports a UNIX system without editing the sys/types.h file to establish the correct typedefs is a fool( this is sort of like expecting machdep.c to port without change! ) > >You are obviously using a 4BSD system. I will try to remember the >correct info for both BSD and USG. > >For BSD, the root partition is always 15884 sectors ("blocks" is >not a good term here, although the code uses it). This is nice >and reasonable for an RP0[456]. It is minimal for the others. >Being LCD, it is thus the standard. This will usually not completely >cover a cylinder on other drives, leading to problems when dd'ing >using a multiple of the cylinder size. Partition B, often used >as swap, is 33440 sectors long. Partition C is the whole disk. >Partition H is the next 291346 (?) sectors, if they are there. >Note that, although 4.1 originally set this up to fit exactly >onto an RP06, because 4.2 skips the bad-block tables at the end >of most HP (DB) drives, this no longer fits an RP06! Anyway, >whether or not partition H is taken out, partition G is the >rest of the disk. Partitions D, E, and F cover partition G. >Partition D is always 15884 sectors, just like partition A. >Partition E is next, often (not always) 55936 sectors. And >Partition F is the rest of Partition G. This allows you to >EITHER use a large partition (G) or three smaller ones (DEF); >OR even to use the whole disc as one FS (C). > >Of course, some sites will munge with the tables and break >this standard. And under Ultrix, this can be changed dynamically >and written on the disk -- something that a comment in the driver >has for a long time said should be done. I like. Some of the >munged non-support, I don't like ... in particular, if mkfs >can't ioctl-read a partition table, it will write a zero-length >partition table onto the drive AND MARK IT VALID -- and then >NOTHING can open and access that drive, even to change the >partition table! (*sigh*) > >Anyway, due to "wasted space" in partitioning, don't believe the >sizes in the table. The standard sizes always do not cover the >partitions (except on the RP0[456]). Believe the entries in >/etc/disktab or your disk manual, instead. > >>Further, it appears that the numbers to use in /etc/mkfs are 1/2 of >>the 'nblocks' number (for "size") along with the standard '3 304' (for >>"m" and "n"). Is this correct? > >Berkeley is trying to get people to think in "Kbytes" rather than >sectors or blocks. So, yes, this is right. > >Now for System V. The only real standard seems to be that the >root partition is 5000 "blocks", and /usr is ... hmmm, that seems >to vary. Anyway, blocks also vary, being either 512 or 1024 >bytes, depending on which file system you look at. (But mkfs >strongly believes in 1024 bytes.) Partition 7 is the whole disk. >Whichever of partitions 1-6 are used seem to start at regular >intervals along the disk, or whatever the designer felt reasonable, >and a lot of designers felt different ways. Each of partitions >1-7, however, include the whole rest of the disc! This is nice, >because then I have a lot of flexibility in how I set up my file >systems. This is VERY NASTY, since then I can destroy a later >file system by writing into earlier partitions. On my RA60's, I >combine partitions 2&3 and 4&5 (6 is empty) into file systems >that are (by no coincidence) exactly the size of my RA81's >partitions. (You see, I planned this when I wrote the driver. >;-)) BUT, I have to keep this written down somewhere, or I >will do something very nasty like creating another file system >on partition 3, in the middle of an existing one. I finally >just made those partitions inaccessible (either mode 0 or I >removed them) (and, yes, root can access mode-0 files -- and >WHO LET YOU do everything as root? you should NEVER use root, >well, unless you really have to. i have discs owned by bin >and mode 400, and everything works REAL nice.). > >I'm beginning to ramble again, aren't I? Ta. Happy Thanksgiving >or Christmas or whenever it is wherever you are. >-- > > Joe Yao hadron!jsdy@seismo.{CSS.GOV,ARPA,UUCP} -- Sarima (Stanley Friesen) UUCP: {ttidca|ihnp4|sdcrdcf|quad1|nrcvax|bellcore|logico}!psivax!friesen ARPA: ttidca!psivax!friesen@rand-unix.arpa