saare@ibmpa.UUCP (John Saare) (01/19/89)
First off, I'd like to thank David Gay for giving my problem some
thought and pointing out some deficiencies in my original posting...
A question to C-A is at the end of this note...
*** LONG APPEND WARNING ***
This is an elaboration of the question I asked earlier in
comp.sys.amiga. This is the scenario:
The hardware:
A500
Pac. Periph. SubSystem 500
Pac. Periph. Overdrive host adapter
Micron 2MB
Adaptec 4000A SCSI to ST-506 xlator.
2x70MB disks (ST-506)(Only 1 is relevant).
The events:
- My Micron 2MB flakes out and is sent off for repair, so I'm running
with 512KB.
- Using PP(Pac. Periph.) utilities of unknown vintage, but that are
at least 1.3 cognizant, I perform a low-level format of a drive
with an interleave of 2. NOTE: There is no defect list available
for the drive. The format completes with no errors reported.
- Using PP utilities, a surface scan is performed. No errors are
reported.
- A mountlist entry is built for the drive. I've heard that Interleave
should be set to 0 for a 1:1, 1 for a 2:1, etc.... I've tried
setting it to both n and n-1. Results appear identical. I've
tried deleting MaxTransfer and setting it to arbitrarily large
numbers e.g., 10000. Because I'm using (was using) the Micron board, I've
set Mask to 7ffff to prevent DMA to fast RAM. I've tried
removing the Micron board altogether (see above).
Other mountlist fields are left as the PP utilities created them and/or
as the C-A dox suggest.
In essence, the mountlist entry for DH0: describes a single partition
encompassing the entire disk.
- I boot under 1.3 and issue the commands:
mount dh0:
format drive dh0: name "SlowBirds" ffs
- The file-system format completes with NO errors, i.e., "verifying"
never complains. It is known that there are errors on this drive, but
not where. It's annoying that NONE of these errors have been caught
up to this point.
- The system runs but disk xfer rates are very slow e.g. 27K/sec ala
diskperf. Nothing I do improves disk performance.
- I install stuff and grumpily procede as normal.
- One day, while compiling (Manx 3.6a for the detail freaks) I get
a R/W error on volume "SlowBirds". I select cancel and then
quarantine the whole directory the error occurred in, using "protect".
- I cross my fingers and continue to use the system over a period of
several days. The system is rebooted before each day's use. Everything
seems fine.
- One day, the machine crashes as a result of an out of memory condition.
- Upon reboot, the disk-validator is run and WILL NOT GET PAST the
allocated bad blocks, so I'm left with an invalid, read-only disk.
- I wait until the Micron board returns (kudos to Micron for fast and
efficient service), re-install it and run DiskDoctor. After ALL
this hoopla, the disk-validator is STILL unable to validate the
disk, running into the bad blocks and failing to procede.
I've become disgusted and re"format"ted the whole mess. I'm sure the problem
will repeat itself. So some questions (some are semi-rhetorical):
- It appears as though if a file-system is EVER formatted with ANY
bad blocks, you will be scr_w_d(I'll buy a vowel Vanna). Is this true?
- The verification step of "format" appears to be mostly a waste
of cycles, doesn't it?
- Given I don't have a practical means of USENET down-loading, are
there any PD(Fish) or commercial utilities that will allow AmigaDOS/FFS
to cope with bad blocks? David Gay mentioned that Disk Mechanic
might do the trick but has problems. Unfortunately I'm unable to
download David's own utility.
- Has anybody experienced throughput problems with the Overdrive/Adaptec
4000a combo? Any solutions?
- If I ever get a working system again, I'll be willing to write a
utility that addresses EXACTLY this problem. Anybody interested?
- This last one is addressed to C-A: I know my system is not
of standard configuration. I know of several difficulties with
the PP host adapter and software aka software. I know of the
difficulties with interactions between the Micron 2MB and other
boards such as the PP host adapter. I believe that I've experienced a
problem that is generic to potentially all AmigaDOS hard-disk
installations. Others have experienced similar problems I'm sure.
The potential bandwidth of FFS is something to be proud of.
I'm sure my problem here has to do with either PP software or
my own ineptitude. The robustness of FFS (and "OFS") should
be of concern. Effectively, permanently invalidating an entire
70MB filesystem because of a few bad sectors just isn't cricket!
Don't you agree?
My thanks to anybody who slogged through this note. Any and all (polite)
suggestions will be appreciated. -- John Saare (uunet!ibmsupt!saare)dsking@pyr.gatech.EDU ( David King) (01/20/89)
In article <695@ibmpa.UUCP> saare@ibmpa.UUCP (John Saare) writes: ... > The hardware: > A500 > Pac. Periph. SubSystem 500 > Pac. Periph. Overdrive host adapter > Micron 2MB > Adaptec 4000A SCSI to ST-506 xlator. > 2x70MB disks (ST-506)(Only 1 is relevant). > > The events: [describes formating system w/ MaxTransfer={high value} and Mask=0x3fff* ] > - The system runs but disk xfer rates are very slow e.g. 27K/sec ala > diskperf. Nothing I do improves disk performance. ... > - Has anybody experienced throughput problems with the Overdrive/Adaptec > 4000a combo? Any solutions? I have had a problem similiar to this one. Here's mine: SYSTEM: Amiga B2000 4.1 revision Pacific Per. OverDrive controller Fuji 30 meg. SCSI disk PROBLEMS: When I first brought up w3FFS{ I followed the instructions in the 1.3 manual which did not have the Mask parameter. Found heavy data corruption. Called up Pacific Per. They sent me the latest version of the software.{ ~rI brought FFS up follwing that and had no problems. I noticed that it was slow, so I hunted down DiskPerf. Had the exact same problem (27,502 kbytes on all buffers). However, I have had no other problems with bad blocks. In fact, I used the slow FFS configuration for the past 3 months as I have tried various solutions. So here's the question: How many people have this problem? What do we have in common? Here's my mountlist: ---- /* OverDrive Drive definition */ /* FUJI FK308S-39R */ DH1: Device = overdrive.device Unit = 2 Flags = 9 Surfaces = 4 BlocksPerTrack = 26 Reserved = 2 Interleave = 0 LowCyl = 1 ; HighCyl = 614 Buffers = 5 BufMemType = 3 /* The following are the OverDrive's parameters for the FastFileSystem */ /* CAUTION:: Refer to the Documentation before attempting to use */ /* the OverDrive with the FastFileSystem. */ /* Comment ON */ GlobVec = -1 FileSystem = l:FastFileSystem Mount = 0 Mask = 0x3fffff Stacksize = 0x800 MaxTransfer = 127000 /* Comment OFF */ # >My thanks to anybody who slogged through this note. Any and all (polite) >suggestions will be appreciated. -- John Saare (uunet!ibmsupt!saare) Thanks for listening, David -- David King Georgia Insitute of Technology, Atlanta Georgia, 30332 uucp: ...!{akgua,allegra,amd,hplabs,ihnp4,seismo,ut-ngp}!gatech!gitpyr!dsking ARPA: dsking@pyr.gatech.edu
disd@hubcap.UUCP (Gary Heffelfinger) (01/20/89)
From article <7086@pyr.gatech.EDU>, by dsking@pyr.gatech.EDU ( David King): > In article <695@ibmpa.UUCP> saare@ibmpa.UUCP (John Saare) writes: > ... >> - Has anybody experienced throughput problems with the Overdrive/Adaptec >> 4000a combo? Any solutions? > > > PROBLEMS: When I first brought up w3FFS{ I followed the instructions in the > 1.3 manual which did not have the Mask parameter. Found heavy data > corruption. Called up Pacific Per. They sent me the latest version > of the software.{ ~rI brought FFS up follwing that and had no > problems. I noticed that it was slow, so I hunted down DiskPerf. > Had the exact same problem (27,502 kbytes on all buffers). > However, I have had no other problems with bad blocks. In fact, I used > the slow FFS configuration for the past 3 months as I have tried > various solutions. > > So here's the question: How many people have this problem? What do we have > in common? Here's my mountlist: Hooboy, does this sound familiar. My setup: b2000 rev 4.(3 or 4) No extra memory PP Overdrive with Seagate ST157N affixed. I have run the PP low-level format with a 1:1 interlace specified. > ---- > /* OverDrive Drive definition */ > > /* FUJI FK308S-39R */ > [Part of mountlist deleted] > /* The following are the OverDrive's parameters for the FastFileSystem */ > /* CAUTION:: Refer to the Documentation before attempting to use */ > /* the OverDrive with the FastFileSystem. */ > /* Comment ON */ > GlobVec = -1 > FileSystem = l:FastFileSystem > Mount = 0 > Mask = 0x3fffff > Stacksize = 0x800 > MaxTransfer = 127000 > /* Comment OFF */ > # Have you tried removing the Mask parm? That way the device can directly access any memory. A month or so ago I removed the Mask, and used a maxtransfer rate of about 16K and got great speed. Then I started seeing gurus when certain programs loaded. So I bumped the Maxtransfer rate down, and down, and down, until the gurus stopped. The number, you ask. 512. One lousy block. The Overdrive software I have appears to be unable to handle the high rates of the FFS. I talked to PP once, but haven't followed up. Give it a try on your system, and see if your's does any better. Gary -- Gary R Heffelfinger - Not speaking for Clemson University disd@hubcap.clemson.edu -- FIX the Holodeck -- Furman Paladins --- National Champs!!
papa@pollux.usc.edu (Marco Papa) (01/20/89)
>In article <695@ibmpa.UUCP> saare@ibmpa.UUCP (John Saare) writes: >> - The system runs but disk xfer rates are very slow e.g. 27K/sec ala >> diskperf. Nothing I do improves disk performance. ^^^^^^^^ Just a side question: where do I get a version of DiskperfA that doesn't leave locks around? Any pointrs to FF disks or such are welcome. -- Marco Papa 'Doc' -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= uucp:...!pollux!papa BIX:papa ARPAnet:pollux!papa@oberon.usc.edu "There's Alpha, Beta, Gamma and Diga!" -- Leo Schwab [quoting Rick Unland] -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
jesup@cbmvax.UUCP (Randell Jesup) (01/20/89)
In article <695@ibmpa.UUCP> saare@ibmpa.UUCP (John Saare) writes: > A500 > Pac. Periph. SubSystem 500 > Pac. Periph. Overdrive host adapter > Micron 2MB > Adaptec 4000A SCSI to ST-506 xlator. > 2x70MB disks (ST-506)(Only 1 is relevant). > - Using PP(Pac. Periph.) utilities of unknown vintage, but that are > at least 1.3 cognizant, I perform a low-level format of a drive > with an interleave of 2. NOTE: There is no defect list available > for the drive. The format completes with no errors reported. The Adaptec should find and map out any errors, though its scan is less thorough than a manufacturers scan. Why didn't the disks have bad sector listing? All st506 drives should have them! > - A mountlist entry is built for the drive. I've heard that Interleave > should be set to 0 for a 1:1, 1 for a 2:1, etc.... I've tried > setting it to both n and n-1. Results appear identical. I've > tried deleting MaxTransfer and setting it to arbitrarily large > numbers e.g., 10000. Because I'm using (was using) the Micron board, I've > set Mask to 7ffff to prevent DMA to fast RAM. I've tried > removing the Micron board altogether (see above). Use 0 for interleave in the mountlist. Maxtransfer should be set to whatever PP suggests, since if it's too large your disk may be corrupted. Maxtransfer is there largely because people wrote drivers that broke when you gave them requests for more than 512 bytes at a time (note that maxtransfer is in bytes, not sectors - the 1.3 docs are wrong). > - The file-system format completes with NO errors, i.e., "verifying" > never complains. It is known that there are errors on this drive, but > not where. It's annoying that NONE of these errors have been caught > up to this point. The adaptec should have caught them. It did, as the verify produced no errors. > - The system runs but disk xfer rates are very slow e.g. 27K/sec ala > diskperf. Nothing I do improves disk performance. Try changing you interleave to 3. Very low xfer rates are the sign of too small an interleave. Small maxtransfers can affect it also, but don't use values higher than the controller manufacturer recommends. > - One day, while compiling (Manx 3.6a for the detail freaks) I get > a R/W error on volume "SlowBirds". I select cancel and then > quarantine the whole directory the error occurred in, using "protect". No guarantees it is actually allocated to that directory. > - I cross my fingers and continue to use the system over a period of > several days. The system is rebooted before each day's use. Everything > seems fine. No revalidation was done. > - Upon reboot, the disk-validator is run and WILL NOT GET PAST the > allocated bad blocks, so I'm left with an invalid, read-only disk. No suprise. It can't figure out what blocks are allocated and what aren't. > - I wait until the Micron board returns (kudos to Micron for fast and > efficient service), re-install it and run DiskDoctor. After ALL > this hoopla, the disk-validator is STILL unable to validate the > disk, running into the bad blocks and failing to procede. Have you tried Dave Haynie's latest DiskSalv? >I've become disgusted and re"format"ted the whole mess. I'm sure the problem >will repeat itself. So some questions (some are semi-rhetorical): If your drive is prone to errors, it probably will. > - It appears as though if a file-system is EVER formatted with ANY > bad blocks, you will be scr_w_d(I'll buy a vowel Vanna). Is this true? Amiga file handlers assume a perfect disk. The _driver_ is supposed to map out bad blocks, including those that occur during use. Since the Adaptec doesn't support the SCSI command REALLOCATE_BLOCK, the driver would have to do the mapping itself. It obviously doesn't. This is a common failing in disk devices on the amiga. > - The verification step of "format" appears to be mostly a waste > of cycles, doesn't it? It works fine. You developed bad blocks later. > be of concern. Effectively, permanently invalidating an entire > 70MB filesystem because of a few bad sectors just isn't cricket! Personally, I use 10-15meg partitions. Greatly reduces the chance of any one problem hurting me, and makes backups easier (since several of the partitions almost never change.) If an FS doesn't validate, it's still readable (you DO keep backups, don't you?) As for speed, try different interleaves and see what produces the best speed. Call PP, make sure your software is up to date, and get the right value for maxtransfer. -- Randell Jesup, Commodore Engineering {uunet|rutgers|allegra}!cbmvax!jesup
perry@madnix.UUCP (Perry Kivolowitz) (01/20/89)
John,
Since you have experienced your problems WITHOUT the Micron memory board
(which is an ASDG design hence this message) I don't have to even mention
that your problem is not caused by the MICRON memory board.
What I would like to add to your understanding is that your problem is
not the FFS, your Amiga, or your hard drive. Have you tried talking to
Pacific Peripherals recently? They're good folks and I think they might
have some new information for you.
--
Perry Kivolowitz, ASDG Inc.
ARPA: madnix!perry@cs.wisc.edu {uunet|ncoast}!marque!
UUCP: {harvard|rutgers|ucbvax}!uwvax!astroatc!nicmad!madnix!perrylphillips@lpami.wimsey.bc.ca (Larry Phillips) (01/22/89)
In <14808@oberon.USC.EDU>, papa@pollux.usc.edu (Marco Papa) writes: >>In article <695@ibmpa.UUCP> saare@ibmpa.UUCP (John Saare) writes: >>> - The system runs but disk xfer rates are very slow e.g. 27K/sec ala >>> diskperf. Nothing I do improves disk performance. > ^^^^^^^^ >Just a side question: where do I get a version of DiskperfA that doesn't >leave locks around? Any pointrs to FF disks or such are welcome. Well, I haven't seen one, but the source to DiskPerfA is readily available. On the other hand, Khalid Aldoseri has written a 'Locks' program that allows you to remove locks that have been left by programs (ARC leaves them when adding files to an archive as well). It's a loaded gun, so caution must be excercised, but it does work, and works properly, if there is such a thing as properly when speaking of messing with another program's legally obtained lock. I'll post it to Bob as soon as I grab the latest version. -larry -- Frisbeetarianism: The belief that when you die, your soul goes up on the roof and gets stuck. +----------------------------------------------------------------------+ | // Larry Phillips | | \X/ lphillips@lpami.wimsey.bc.ca or uunet!van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 | +----------------------------------------------------------------------+