hp.c (4.1bsd)

[Stanley Friesen]

In article <100 at hadron.UUCP> jsdy at 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 at seismo.{CSS.GOV,ARPA,UUCP}


-- 

				Sarima (Stanley Friesen)

UUCP: {ttidca|ihnp4|sdcrdcf|quad1|nrcvax|bellcore|logico}!psivax!friesen
ARPA: ttidca!psivax!friesen at rand-unix.arpa