Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site brl-tgr.ARPA Path: utzoo!linus!philabs!cmcl2!seismo!brl-tgr!tgr!eichelbe@nadc.ARPA From: eichelbe@nadc.ARPA Newsgroups: net.unix-wizards Subject: 4.1 BSD mkfs(8) for an RA81? Message-ID: <2778@brl-tgr.ARPA> Date: Mon, 4-Nov-85 09:49:20 EST Article-I.D.: brl-tgr.2778 Posted: Mon Nov 4 09:49:20 1985 Date-Received: Tue, 5-Nov-85 21:37:54 EST Sender: news@brl-tgr.ARPA Lines: 40 In the near future we will be installing 3 DEC RA81 disk drives and a UDA50 controller onto our VAX 11/780, which is running 4.1 (NOTE: that's 4.1) BSD UNIX. We do not have anything like the newfs utility on 4.2 BSD. We are stuck using the 4.1 BSD utility mkfs(8). The call to this utility is of the form: /etc/mkfs special size [m n] (at least how we use it). The man page for mkfs(8) says that the 'special' parameter is the file partition (e.g., /dev/rhp2g) and the 'size' parameter is the size of the file system in kilobytes. No problem so far. Now, although the manual page seems to specify the 'm' and 'n' parameters as optional, we have always supplied them as the manual page says 'm' should always be 3 and 'n' should be as given in the following table: RM03 80 RM05 304 RM80 217 RP06 209 RP07 800 SI/CDC 9766 304 RK07 33 EMULEX/AMPEX 300M 304 EMULEX/FUJITSU 160M 160 The manual page calls the 'm n' pair the interleave factor. What does this mean? Since there was an 'n' for the SI/CDC 9766 drives we have, there was no problem. But there is no entry for an RA81. My questions are: (1) Is it OK to leave off 'm' and 'n', and will the mkfs(8) utility do the 'right thing' for me? For an SI/CDC 9766? FOR AN RA81???!!! (2) If I want to specify 'm' and 'n' for the RA81, what should the values be? Again, let me stress that I am under 4.1 BSD UNIX, and I have no newfs utility. (3) Although this is the least important question, how do you figure out 'm' and 'n', given a brand X drive with a brand Y controller for it? (Actually, this may be the most important question in the long run.) Thanks. Jon Eichelberger eichelbe@NADC.ARPA