Does controller translation affect throughput?

[David Schachter]

My system includes a WD1007 disk controller and two drives.  The first drive,
which has been working well, if slowly, since it was installed, is a Micropolis
1355.  The system is an Everex Step 386/20, 4MB RAM, running XENIX V R2.3.2.

Question: The first drive shows as 1023 cylinders, 16 heads, 17 sectors per
track.  Of course it has 8 heads and 34 (or possibly 35) sectors per track,
with the controller translating.  (35 SPT if the disk was formatted with a
spare sector.  I believe this would cause most disk flaws to be invisble to
XENIX as the controller maps them to the spare sector.  Right?  Or does XENIX
still see them, and badtrk maps 'em out?)

Is this configuration losing performance?  Should I reformat and disable
translation to return to 1023 cyl., 8 heads, 34|35 SPT?

Other question: the second drive I installed last night is a Fujitsu MK2244E,
823 cylinders, 5 heads, 34 (or 35) sectors per track.  I used the WD BIOS
extension to format and surface-analyze the disk, then XENIX utilities to use
the entire disk for a XENIX partition as the disk 1 on controller 0, and
manually created the filesystem with 40000 inodes, instead of the default ~15K
inodes, so it will hold lots of small files.  (And I manually created the lost+
+found directory and put a bunch of files in it and deleted them.)  Basically,
I followed the instructions in the XENIX documention until the mkfs step and
then followed USENET instructions for choosing inode capacity (which is mostly
a manual execution with modest variations of the /usr/lib/mkdev/fs script.)

The drive mounts fine, df is happy, and I can create files on it and read them
back.  But when I try to copy a lot of stuff to it (the news spool area, for
example,) it churns away for a bit, copying files, and then hangs.  Hangs the
whole system, in fact.  The drive selected light stays on, I can't login or
execute any disk-based commands (as opposed to csh builtins) and the system 
must be reset and rebooted.

Any ideas what is wrong?  I didn't enter the manufacturer's defect list to
badtrk, as I presumed the WD BIOS surface analysis routine mapped those defects
out when I entered the list to it.  I.e., I assumed XENIX wouldn't see the
defects because the defect list no longer corresponded to XENIX's view of the
disk.

One stupidity up front: I haven't installed xnx133 yet, the WD1007 fix.  I'm
not entirely sure what it does.  Perhaps if I do, the problem will go away?
Does anyone know what xnx133 does?

If anyone cares, I HAVE been reading recent traffic in this newsgroup on the
subject of disks and controllers, and I HAVE been reading the manuals, and the
controller documentation and disk drive documentation, and I'm not entirely
stupid, only mostly.

					-- David Schachter
					   llustig!david at mips.com  OR MAYBE
					   david at llustig.uucp

					   +1 415 328 7425