On Mar 6, 12:25pm, I wrote:
} Subject: Problems formatting Maxtor drive
}
} Configuration:
}
} o SPARCstation 1+
} o SunOS 4.1
} o Sun 104MB internal drive (sd0) - 1 partition mounted on /usr
} o Maxtor XT-8760S (sd3) - with /, swap, and /home
} o geometry we are using for the Maxtor: ncyl=1626, acyl=2,
} pcyl=1632, hds=15, sect/trk=51
}
} We reformatted the Maxtor drive (hopefully to map out some bad blocks on the
} drive). So we restored the root partition, /dev/sd3a, with no problems.
} After finishing the restore we boot off /dev/sd3a, only to have the machine
} crash in rc.single when it remounts the filesystems, saying
}
} BAD TRAP
} pid 20 `mount' Text Fault
} bad kernel read fault at addr <some address>
} Sync Error Reg 80 <INVALID>
}
} So just for fun we did a newfs on /dev/rsd3a and redid the restore on the
} root partition, and immediately ran fsck, which then finds many problems,
} like "DIRECTORY CORRUPTED" and "MISSING '.'" and "MISSING '..'" problems.
} We had also tried doing the restore of /home to /dev/sd3g after running
} newfs. However, very soon after starting restore we get a "PANIC: ialloc,
} dup alloc" (something close to that, I'm working from my memory of the
} events of a few days ago).
}
} We then run newfs on /dev/rsd3g, and just to make sure things are OK,
} we run fsck on /dev/rsd3g. We get many errors, starting with things like
} "UNKNOWN FILE TYPE I=14400" (and about 6 or 7 more, and then some "DIRECTORY
} CORRUPTED" messsages, and "MISSING '.'" and "MISSING '..'" associated with
} the corrupted directories. So we ran "fsck -y", but the errors are not
} fixed. The drive is terminated properly, and the partition table does not
} have any overlapping partitions. This drive worked fine under SunOS 4.1 for
} months, with no problem, but was originally installed, formatted under SunOS
} 4.0.3. After running format we can't get the drive to work. We have tried
} connecting the machine to a 3/60, same errors. We also tried doing the
} newfs with 4.0.3c version of newfs/mkfs, to no avail. We have had the disk
} swapped at least 3 times in the past 2 weeks, same results.
}
} I am at the end of my list of things to try. Anyone have any idea as to
} what to look for/try? Thanks.
}
}-- End of excerpt
I got the following replies:
1> Quoting johnb@edge.cis.mcmaster.ca,
1> > o geometry we are using for the Maxtor: ncyl=1626, acyl=2,
1> > pcyl=1632, hds=15, sect/trk=51
1> Not sure why you are using that geometry. The real geometry
1> is 1632/15/54, they you take out the cylinders that the SCSI init used
1> for internal bad track mapping and it gives you ncyl=1613 and a totally
1> clean disk.
This answer comes close (looks a lot like the format.dat that comes in SunOS
4.1, but is commented out!-).
2> We have recently resolved (we believe) some nasty problems which were due
2> to a SCSI chain that was too long. We had two internal disks, two
2> external disks, and one external tape drive. The standard cable length
2> was 6 feet and internal to the disk drive enclosures there was anywhere
2> from 12 to 24 inches of cable. All added up it was very long.
2> The symptoms included everything from explicit SCSI errors and fsck errors
2> to virtual memory errors, we were absolutely convinced that one of the
2> drives was bad but when any device was removed from the bus, all
2> remaining devices would pass diagnostics.
2>
2> Have you tried running sundiag?
This is the only external SCSI device, and the cable is only 3 ft (or so)
long.
3> You say you "reformatted" but you give no details. Did you do all
3> the magic with the defect list? Did you do a couple of verify
3> passes? Do those ...
Yes, we made sure that we did the defect list management, but, to no avail.
4> I know you checked it, but check it again. This sounds very much
4> like overlapping partitions.
That was my first guess too, but it definitely wasn't a problem.
After much fiddling, we decided to use the following in format.dat:
disk_type = "Maxtor XT-8760S" \
: ctlr = MD21 \
: cache = 0x11 : trks_zone = 15 : asect = 2 : atrks = 30 \
: ncyl = 1626 : acyl = 2 : pcyl = 1632 : nhead = 15 : nsect = 52 \
: rpm = 3600 : bpt = 31410
There seems to be 4 cylinders reserved for use by the disk, i.e. ncyl+acyl
is 4 cyl less than pcyl. Also, we guessed that the drive has 54 sect/trk,
so nsect+asect=54, and USDC (who makes the Maxtor) said to use nsect=52,
sooooo... asect=2 seemed a natural. This was the one that seemed to make
all the difference, because we were already using the above cylinder
geometry. As soon as we put in nsect=52, asect=2, we could newfs/restore
with no problem. The disk is being used heavily for image processing using
IRAF for the last 5 days or so with no further problems (I bet Gerald
Justice knows exactly what IRAF does:-).
Many thanks to those who replied:
syd@dsinc.dsi.com (Syd Weinstein)
Gerald Justice <justice@dao.nrc.ca>
"Matt Crawford" <matt@oddjob.uchicago.edu>
del@mlb.semi.harris.com (Don Lewis)
-- E. John Benjamins BITNET: JOHNB@MCMASTER Computer and Information Services, Internet: johnb@edge.cis.mcmaster.ca ABB 131, McMaster University, voice-mail: (416)525-9140 ext. 2920 Hamilton, Ontario, Canada "You can't chop down a symmetry" -- Jane Siberry
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:12 CDT