SUMMARY / newfs

From: Kim Love (
Date: Fri Feb 02 1990 - 16:36:58 CST

Thanks for all of the helpful responses! My problem turned out to be a
little more unique. There is a problem with the 892 Mbyte NEC
disk. A Sun PAL Engineer, Rod Livingood, came up with my solution. I had
to rename, repartition, and relabel the disk. A lot of people pointed
out that I couldn't use the -b 4096 option. I am attaching most
of the mail messages I received...and my real solution at the end.

From: (Ron Gaug)

This problem has been around for quite a while. The following was taken
from Sun-Spots Digest Volume 7 Issue 32:

Date: Fri, 18 Nov 88 21:15:02 -0500
From: (Jeff Smith)
Subject: Re: Problems with Fujitsu-M2382K on Xylogic 735 on a 3/280

> We recently received a Fujitsu-M2382K on Xylogic 735 and I was trying to
> set it flying on a 3/280 when I ran into problems with insufficient inodes
> in the client root partition...
> (1) how come the "-i" option in "newfs" didn't do what the manual says
> it should do (I know, I know, manauls lie all the time :-< )?

actually, it does. If you use "newfs -vN" you can see what it passes to
mkfs without actually running mkfs (make sure you use 'N' and not 'n'!).
Newfs passes the -i parameter to mkfs, which then silently adjusts the
number of inodes to what it thinks is right.

The real problem is with the constant MAXIPG in ufs/fs.h. This is set to
2048 and puts a ceiling on the number of inode blocks per cylinder group.
Mkfs actually uses 2048 if you tell it to, but that's the maximum. There
are more sectors per cylinder in big drives than in older, smaller ones,
e.g., there are about 900 sectors per cylinder in a Fujitsu Eagle, and
2241 in a Fujitsu Swallow IV. Since the maximum number of inode blocks
per cylinder group is constant but the number of data blocks varies, the
percentage of inode blocks per data blocks is smaller in the Swallow IV
than in an Eagle. Using 8 cylinders per cylinder group doubles the
percentage of inode blocks by halving the number of data blocks per
cylinder group. You have to use a 4k/1k file system to have 8
cylinders/cylinder group.

As you noted, this has the undesirable side effect of crashing the host
when you attempt any reference to that file system. The stack backtrace
looks like this:

    _panic(0xf076d88) + 44
    _segmap_unlock() + 7a
    _segmap_fault(0xf0de000,0xfb3c000,0x2000,0x3,0x0) + 8e
    _as_fault(0xf07e6a8,0xfb3c000,0x400,0x3,0x0) + a0
    _fbrelse(0xf0e5d44,0x0) + 1e
    _dirlook(0xf09e5b8,0xffff95bc,0xffff9570) + 2fc
    _ufs_lookup(0xf09e5c0,0xffff95bc,0xffff96bc,0xf0e5140,0xffff96e0,0x0) +1a
    _au_lookuppn(0xffff96e0,0x1,0x0,0xffff976c,0x0) + 20e
    _au_lookupname() + 34
    _lookupname(0xefffc4e,0x0,0x1,0x0,0xffff976c) + 1a
    _stat1(0xffff9a18,0x1) + 1a
    _stat(0xffff9a18) + c
    _syscall(0x26) + 15a
    syscont() + 6
    data address not found

> (2) is there something peculiar with the geometry of the M2382K that
> restricts the choice of # of cyl/grp as mentioned above?
No, the cyl/grp choice is wired into mkfs because it's wired into the file

> (3) does anyone has a possible work around for this problem?

Wish we did. We've reported the bug to sun.

Jeff Smith,
Purdue University, 210 Math Science, W. Lafayette, IN 47907, 317/494-1787

-----------End of SunSpots Digest Volume 7 Issue 32------------------

And here's another pertinent article which appeared in comp.unix.wizards

>From ames!umd5!mimsy!chris Sat Aug 6 14:22:05 PDT 1988
Article 5502 of comp.unix.wizards:
Path: amelia!ames!umd5!mimsy!chris
>From: chris@mimsy.UUCP (Chris Torek)
Newsgroups: comp.unix.wizards
Subject: Re: mkfs/newfs: not enough inodes (SunOS 4.0)
Summary: rerun of comp.unix.questions answer
Message-ID: <12798@mimsy.UUCP>
Date: 2 Aug 88 17:50:33 GMT
References: <>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 121
In article <>
(Alexander Dupuy) writes:
>... under SunOS 4.0, mkfs/newfs say:
> "cylinder groups must have a multiple of 16 cylinders"
>From: chris@mimsy.UUCP (Chris Torek)
Newsgroups: comp.unix.questions
Subject: Re: mkfs problem
Date: 8 Jul 88 23:15:48 GMT
In article <699@natinst.UUCP> brian@natinst.UUCP (Brian H. Powell) writes:
>I'm having trouble getting the bytes/inode parameter to newfs/mkfs work
>like I want it to. Normally, it uses 2048 bytes/inode.
Sometimes. You are getting about 7K/inode, for reasons to be explained
in a moment.

>I want four times that many, so I want 512 bytes/inode.

This is rather excessive. 2K/inode usually provides more than twice as
many inode as you really need. On file systems with many tiny files,
you might average as low as 1.5K/inode, or even 1K/inode. 512 bytes
per inode, though, would mean not only that every file would have to
be <= 512 bytes long, but every directory would also have to be <= 512
bytes long. Four times your current allocation is just a bit under

>natinst# /etc/newfs -n -v -i 512 /dev/rxl0e
>/etc/mkfs /dev/rxl0e 390744 67 27 8192 1024 16 10 60 512 t 0
>/dev/rxl0e: 390744 sectors in 216 cylinders of 27 tracks, 67 sectors
> 200.1Mb in 14 cyl groups (16 c/g, 14.82Mb/g, 2048 i/g)

Look at the numbers in the last line: 16 c/g, 14.82MB/g (Mb is just
wrong; the sizes are bytes, not bits! :-) ), 2048 i/g. Translation:
16 cylinders per cylinder group, 14.82 megabytes each, with 2048
inodes each. That is 2048 inodes per 14.82 MB of inode+data space,
or just under 7 KB of data space per inode (the inodes take part of
that 14.82 MB, as each inode consumes 128 bytes). Given that there
are 16 cylinders per group, and that 16 cylinders is 14.82 MB, to get
512 bytes per inode, you should see:

        512 bytes * #i + 128 bytes * i = 14.82 MB [1]
        640 bytes * #i = 14.82 MB
        #i = 14.82*1024*1024 / 640

or around 24000 inodes per group! Where did they all go?

>What's going on?
[1] these calculations are somewhat off; there is also a block map
in each cylinder group. Still, they are good enough for demonstration

What is going on is that there is (was) a hard limit in the way:

% egrep MAXIPG /sys/ufs/fs.h (on a Sun)
 * MAXIPG bounds the number of inodes per cylinder group, and
 * N.B.: MAXIPG must be a multiple of INOPB(fs).
#define MAXIPG 2048 /* max number inodes/cyl group */
        char cg_iused[MAXIPG/NBBY]; /* used inode map */
Now, you cannot just raise MAXIPG wantonly; indeed, if you do not
have source, you cannot raise it at all. So what *can* you do?

There is a `-c' parameter to newfs, described as

     -c #cylinders/group
               The number of cylinders per cylinder group in a
               file system. The default value used is 16.

If you lower c/g, you will lower MB/g. A smaller MB/g will give
a smaller MB/inode ratio if i/g remains fixed. Hence

        newfs -c 4 /dev/rxl0e

should give you `around' 2K/inode. Of course, your cylinder groups
will be very small, which is not terribly advantageous.

But there is another problem. Newfs cannot lower c/g below 16 when s/t
and t/c are 67 and 27 and the blocksize is 8K [2]. So now what? It
might work to claim that the device has only 66 sectors per track,
which would let you use a c/g of 8; this loses 27 sectors, or 13.5KB,
per cylinder, and goofs up the allocation policies, unfortunately. Or
you could use a blocksize of 4K, but that prevents paging on a Sun 3.

[2] The problem has to do with the fact that 67*27 = 1809, which is
odd, or more precisely, has no 2s in its prime factorisation. The
magic calculations, from the 4.3BSD-tahoe newfs, are:

        sblock.fs_spc = secpercyl;
        for (sblock.fs_cpc = NSPB(&sblock), i = sblock.fs_spc;
             sblock.fs_cpc > 1 && (i & 1) == 0;
             sblock.fs_cpc >>= 1, i >>= 1)
                /* void */;
        mincpc = sblock.fs_cpc;
        bpcg = sblock.fs_spc * sectorsize;
        inospercg = roundup(bpcg / sizeof(struct dinode), INOPB(&sblock));
        if (inospercg > MAXIPG(&sblock))
                inospercg = MAXIPG(&sblock);
        used = (sblock.fs_iblkno + inospercg / INOPF(&sblock)) * NSPF(&sblock);
        mincpgcnt = howmany(sblock.fs_cgoffset * (~sblock.fs_cgmask) + used,
        mincpg = roundup(mincpgcnt, mincpc);

secpercyl is 67*27; fs_cpc (cylinders per rotational position cycle) is
(8192 bytes/block) / (512 bytes/sector) or 16 sectors/block. This gives
a mincpc of 16, which carries on down into mincpg.

In short, there are really no good solutions. 4.3BSD-tahoe has
eliminated the 2048 MAXIPG limit; MAXIPG is now computed as one third
of the space in a cylinder group (via the MAXIPG(&sblock) macro
above). We can hope that Sun will pick up Kirk's new code quickly.
Until then, well, you may just have to create bigger files. . . .

In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:     Path:   uunet!mimsy!chris

Hope this sheds some light onto the problem. I think Sun published something about this particular problem in one of their Software Technical Bulletins. I don't have mine handy at the moment or I'd check. If you don't find any good solutions, send me some email and I'll dig them up.

Good Luck!

Ron Gaug or ******************************************* From: (Mark Wallen)

I've had REAL bad luck with fragsize 512 on 4.0.X. I just gave up and used 1K frags The exact problem I was having was on a sun2 server running 4.0.X; binaries stuck on the 512 fragsize file system would jsut crash when you started them.

********************************************* From: (]ke Sandgren)

> I have just installed a 3/480 server running SunOS 4.0.3. I am > trying to remake one of the filesystems on my xd1 disk. Everything > I've tried, (other than the newfs /dev/rxd1a), crashes the system after > I mount the partition and do some other command, such as 'ls'. I do > a fsck on the partition everytime I newfs it, but that doesn't > help. The message I get as the system crashes is: panic: segmap_unlock. > > Here are a few of the newfs commands I've tried: > > newfs -b 4096 -f 512 -c 8 /dev/rxd1a > newfs -b 4096 -c8 /dev/rxd1a > newfs -c 8 -i 512 -m 10 -b 4096 -f 512 /dev/rxd1a This is something that we also had trouble with, blocksize < 8192 and fragsize < 1024. This might have to do with the fact that SUN 3's (as far as i know) uses a page-size of 8192 and therefor bangs if you give it a blocksize which is less than this amount. If you get any other solution that is able to use a blocksize < 8192 i would really like to know.

> I need more inodes on this partition so that I can install news...does > anyone have any suggestions?? As long as you keep away from 4096/512 sizes, you can manipulate all the other options to newfs and still get a usable partition.

> Many Thanks, > Kim Love >

Good luck! /]ke Sandgren

************************************ From: (David Robinson)

Simple problem, specify the blocksize to be 8K instead of 4K. SunOS 4.0.X requires that the filesystem blocksize be >= the hardware page size, so minimums are: Sun-2: 2K Sun-3: 8K Sun-4: 8K (except 4/60) Sun-4/60: 4K

We are running news on a 4/370 and have hit this problem. A quick study shows a waste of 18-20% with an 8K/1K filesystem but there is not much that can be done. The new VM system requires this. Fixed in 4.1? I doubt it but possibly. ************************************ From: Bill Vaughn <>

I had the same problem when I tried to make a partition with a block size of 4096 and a fragment size of 512. Since I was just testing my disk on that partition I resigned to using -b 8192 and -f 1024 (the defaults). This is definitely a bug, but due to time contraints and many other things to do, I haven't reported it, especially since I can live with the defaults.

In my case the system crashed only after 'cd'ing to the newly mounted partition. The mount command completed normally. I did this twice before I realized just what was causing the crash.

This just happened to me two weeks ago. I guess it's time to report this bug.

Bill Vaughn Univ. of Rochester, Rochester, NY ******************************************* From: (Jason Heirtzler)

The problem is that the filesystem blocksize can't be less than the pagesize (8k)

The general strategy in this sort of things is to reduce the size of a cylinder group therefor to increase the number of inodes (ino/cyl-group is fixed at 2048?)

If you haven't gotten a zillion responses, let me know and I'll dig up what I did over here to change it.

******************************************* From: (Per Westerlund)

I don't have a Sun-3/480 myself, but if they haven't changed the architecture to much the page size of the hardware is 8 kbytes. There is a note in the "Read This First" for SunOS 4.0 that says that you can not have a file system with smaller blocksize than the page size of your system. Sorry, can't win them all.

Per Westerlund *************************************** >From bcstec!sleepy!louie!anthis@uunet.UU.NET Wed Jan 31 15:36:12 1990

Just a dumb question from me: have you verified that your paritions on the disk are not overlapping? The system will not prevent you from creating overlapping partitions.

If you're overlapping into another filesystem, or the swap area, things get clobbered. One of the "bugs" of mount(8) is "Mounting filesystems full of garbage crashes the system".

You might try an fsck against the new filesystem AFTER the crash, if that's possible. ********************************* From: rodo@Sun.COM (Rod Livingood USAC/PAL)

Rod Livingood USAC/PAL Engineer


Introduction ------------

This message defines a solution for the file system bug that occurs with certain partitioning of the NEC drive. The purpose of this message is to describe the solution in enough detail to facilitate solving customers' problems.

Symptom Definition ------------------

Fluke and other customers complained that when they created small file systems on the NEC drive, they ran out of INODES long before they ran out of partition space. Consequently, they were not able to have small file systems (~10 MB) that contained lots of small files, they way they could with the Hitachi 892 MB drive. Even though the drives had equivalent capacity, they could not be used for exactly the same things.

Thus, the NEC was deemed an unacceptable substitute for the Hitachi drive.

Current Solution Strategy -------------------------

Many solutions were analyzed and attempted. For practical reasons, the solution must be broken into three phases: for the short-term, medium-term, and long-term. This message really deals only with the short-term solution, but the longer-term solutions are being worked. The solution strategy is:

1. Short-Term : for installed systems, the strategy is to repartition the NECs in the field; this should take about 30 mins. per drive (this should only be done for those customers that really need the change) 2. Medium-Term : all new drives will be manufactured with the partitioning described herein; no rework should ever be required. 3. Long-Term : the "BSD-4.3Tahoe" file system changes are incorporated into SunOS, to completely remove the problem for all drives.

Short-Term Strategy: Overview of Procedure -------------------------------------------

The procedure described below should resolve all symptoms in this area. The procedure can be performed in about 30 minutes by a technician (customer or Sun) with root/super user privileges, doing the following: 1. take NEC disks off line 2. back NEC disks up 3. repartition them (NOT reformat) 4. create new file systems 5. copy data back onto the NECs 6. bring disks back on line

A detailed step-by-step procedure is appended to this message.

Advantages ----------

* Solves the customers' problem * Allows us to continue NEC shipments (important revenue impact) * Very simple -- no change to file system * No decrease in capacity or performance--the drives become functional equivalents * Doesn't involve reformatting drives or taking the system down * Can be done by customer, or remotely by Sun engineers (via rlogin) * Takes little time

Why it works ------------

The file system bug is aggravated by disks that have few, large, cylinders; for example, the NEC parallel-head design has 1024 cylinders of about a MB each (compared to Hitachi's 1700 cylinders of about 600 kB each). The bug is sensitive, among other things, to the number of sectors per track (normally 67 on SMD drives).

By reducing the number of sectors per track on the NEC to 64, we can avoid the file system bug. The file system will now let us dramatically reduce the number of cylinders per group, which greatly increases the available INODES per file system. In fact, the NEC can now have MORE INODES than an Hitachi drive. This procedure reduces the capacity per track by about 5%; fortunately, the NEC actually has more capacity than the Hitachi, and Sun has traditionally "formatted down" the NEC to the advertised 892 MB. By using some of the 60 "spare" tracks available in the NEC, we obtain the same total capacity for the drive. The file system and disk controller (SMD-4) appear to operate normally with the changed format parameters, and performance should not be affected.


Step-by-Step Procedure for Installed Systems --------------------------------------------

0. Make sure the customer is concerned with this issue. Since this procedure involves a full backup and restore cycle, it should not be done unless it's necessary.

1. Log in as root/su. Use the "script" command to create an audit trail of what you are doing. "Wall" to all system users that the file systems/ partitions on the NEC disk(s) will be taken off-line and unavailable for at least an hour. Umount all file systems on the NEC disk(s). Kill any processes that use raw partitions on the NEC disk(s). Back up all data on the NEC disk(s). This should be a level-0 dump for each of the file systems, or a dd for each of the "raw" partitions.

2. While the backup is running, calculate new partitioning parameters for 64 sectors/track, instead of 67. See Appendix A if you don't know how.

3. When the backup is complete, remove the tape(s) from the drive and label them.

4. Type "format." (note that there is no man page for get help by typing "?" at the prompt). The utility should produce a list of "available disks." Note the number of any NEC disks, and enter the number (0-N) of the disk you want to work on.

5. The format utility will prompt you for the number of bytes/sector. You can just hit return, but FYI the correct number is 600. You will now be given the "format>" prompt. Type "current," just to confirm that you are looking at an NEC drive. As an OPTIONAL step, type "defect", followed by "dump", followed by a file name on a *non*-NEC disk, followed by quit. This creates a backup copy of the disk's defect list, which is just a precaution (but generally a good idea).

6. Type "type," to define a new disk type. The utility will produce a list of "available" drives, one of which will be "NEC D2363." At the bottom of this list will be "#. other". When you are prompted to specify the disk type, enter that #. Then enter: 1009 (for data cylinders)* 2 (for alternate cylinders) 1024 (for physical cylinders) 27 (for number of heads) 64 (for number of data sectors/track)* 3600 (for RPM) 600 (for total bytes/sector) "nec alt-892 MB" (for disk type name)

The asterisked entries are the ones that change the geometry and make this solution possible. Once you enter the disk name, format should indicate that it's selected the disk hardware and type, that it found the disk formatted and with a defect list, but WITHOUT defined partition tables.

7. The "format>" prompt will return; type "current" to ensure you're looking at your new creation. Do NOT type "type" again from here on, as it will cause a core-dump (this is a bug in the utility).

8. Type "partition" to enter partitioning mode; at the new prompt, type "print" to show the current table (which will be filled with zeroes). Next, type "a" to specify the `a' (commonly, the root) partition. Enter the values you calculated in step 2 (or, see Appendix A). Repeat the data-entry cycle for each partition you want to define. Note that you are allowed to enter the number of blocks either directly as an integer, or as three integers representing cylinder/track/sector, if you are more comfortable with that. An example set of partition parameters, for typical users, is:

Partition Starting cylinder No. of Blocks MB --------- ----------------- ------------- ---- a 0 32832 (or 19/0/0) 16.8 b 19 67392 (or 39/0/0) 34.5 c 0 1743552 (or 1009/0/0) 892.7 d 58 39744 (or 23/0/0) 20.3 e 81 39744 (or 23/0/0) 20.3 f 104 15552 (or 9/0/0) 8.0 g 113 857088 (or 496/0/0) 438.8 h 609 691200 (or 400/0/0) 353.9

When you are done entering these, type "print" to display the completed table, and double-check all entries.

9. Type "name". Name the partition table "nec alt--892 MB". Type "label", and type "y" to continue. Type "quit" to return to format's main menu.

10. Type "disk", and note that the disk label name has changed from "nec alt-892 MB" to "nec alt--892 MB". Type "quit". As an OPTIONAL step, you may choose to cycle power on the system to fully reinitialize the system and controller. This should not be required, but can't hurt any.

11. You now have a fully usable disk, providing all you use is raw partitions. Most users need file systems, however, on the a and d-h partitions. For each file system to be created, use the newfs command as follows: newfs -c NN -i 2048 /dev/rxdNA

where: NN is an appropriate number of cylinders per cylinder group (the default is 16, but NN should be about half the number used for the Hitachi disk; for very small file systems on the NEC try 3 or 2 cylinders per group) N is the disk number for the NEC (0-15) A is the alpha character for the partition (a-h); note that under most circumstances it is very unwise to make the b or c partitions into file systems!

When you use this command, be very careful about typos! Newfs will echo back all kinds of interesting stuff about the file system being created; write it down in the system log for future reference. (Or print out the "script" file.)

For the example partitioning of step 8, the following commands would be used:

newfs -c 8 -i 2048 /dev/rxd0a newfs -c 8 -i 2048 /dev/rxd0d newfs -c 8 -i 2048 /dev/rxd0e newfs -c 3 -i 2048 /dev/rxd0f newfs /dev/rxd0g newfs /dev/rxd0h

12. Mount the file systems, as appropriate; for example:

mount /dev/xd0a / mount /dev/xd0d /usr mount /dev/xd0e /usr1 mount /dev/xd0f /mnt mount /dev/xd0g /home mount /dev/xd0g /home1

13. Type "df" to check that the file systems are available.

14. Restore the data to the file systems/partitions, spot-checking the files to ensure that they are readable.

15. "Wall" users, to notify them that their data is on-line. Kill the script process. As an OPTIONAL step, you may want to edit /etc/format.dat, to reflect the new partitioning (see Appendix B for "before" and "after" examples)

Appendix A: Calculating Partition Sizes for Fun and Profit

If you already know how to calculate partition sizes, don't read on. Otherwise, get your calculator and a sheet of paper.

The objective of this procedure is to create a "standard" partitioning for file system use. The partitioning will be suitable for "/" on partition a, swap on b, "whole disk" on c, and file systems on d-h. Such oddities as overlapping partitions are avoided.

For the NECs, you'll have a total of 892.7 MB available. That is 1009 cylinders, composed of 27 tracks/cylinder, 64 blocks/track... or 1,743,552 blocks of 512 bytes each. The disk actually has more cylinders than that, and more blocks/track, and more bytes/block, but those aren't usable.

First, figure out how you want to allocate the 892.7 MB among the partitions. Typically, the "a" partition should be >31768 blocks (>16 MB) and the "b" partition should be >66880 blocks (>34 MB). The c partition is usually the whole disk (1,743,552 blocks, or 892.7 MB), and the rest of the partitions (d-h) can be set up however the user wants them.

Partitions always start on a cylinder. And you should start with partition "a" and go sequentially through the rest. So the "a" partition must start on track 0. How big should the "a" partition be? Get out your algebra texts:

Min size of "a" is 31768 blocks; Cylinders are 64 x 27 (1728) blocks each; Number of cylinders must be integer; so,

C * 1728 > 31768, so

C > 31768/1728, so

C > 18.38, so

C = 19

So the a partition must be 19 cylinders long, and will occupy 32,832 blocks.

The b partition is sized the same way. The only thing to remember is that you will be starting at cylinder 19, rather than cylinder 0.

The c partition is easy, as it's the whole disk. It starts at cylinder 0, and occupies 1009 cylinders.

The d-h partitions are sized the same way as a and b; the trick is, the partitions should start at precisely next cylinder after the previous partition left off. See the example partitioning in step 8 of the main procedure.

Write all this partitioning information down on your notepad, and make sure it all adds up *before* you start the repartitioning. If you have trouble, don't call me...get in touch with a system administrator or guru who's done this before ("do not try this at home").

After you've entered the partitioning information into the "format" utility, you can cross-check your work. Using the "print" command of the "partition" mode, you get a table that indicates the number of blocks in each partition, as well as the cylinder/track/sector count. Make sure that each of the partition sizes is (N/0/0), where N is any number. If the second or third numbers aren't 0, you've miscalculated somewhere. Also, make sure that the starting cylinder of each partition is equal to the starting cylinder of the previous partition plus the "N" number of cylinders occupied by the previous partition (except for c, which is unique).

Appendix B /etc/format.dat changes


disk_type = "NEC D2363" \ : ctlr = XD7053 \ : ncyl = 964 : acyl = 2 : pcyl = 1024 : nhead = 27 : nsect = 67 \ : rpm = 3600 : bpt = 40960 : bps = 600 ------------------------------------------------------------------------------

partition = "NEC D2363" \ : disk = "NEC D2363" : ctlr = XD7053 \ : a = 0, 32562 : b = 18, 66933 : c = 0, 1743876 : g = 55, 1644381


AFTER------------------------------------------------------------------------- disk_type = "NEC D2363" \ : ctlr = XD7053 \ : ncyl = 1009 : acyl = 2 : pcyl = 1024 : nhead = 27 : nsect = 64 \ : rpm = 3600 : bpt = 40960 : bps = 600


partition = "NEC D2363" \ : disk = "NEC D2363" : ctlr = XD7053 \ : a = 0, 32832 : b = 19, 67392 : c = 0, 1743552 : g = 58, 1643328


This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:05:56 CDT