If anyone is interested, I thought I would share my continuing trials with failing SCSI hard drives. I suppose this stuff will be pretty obvious to many ppl, but, it has been quite a journey for me. I previously started talking about this here: "What is the precise 4 Gig limit?" It seems neither drive was past the 4 Gig barrier, I have no idea why they corrupted the way they did. A corrupted file copied to both maybe.
I have recovered one of two of the 4 Gig Quantum SCSI hard drives (Both corrupted in 2010 within a month of each other. Both were installed together in the same machine, one as a backup for the other. See sig below.) I have not attempted the other twin drive yet. I have, OTOH, seemingly destroyed two other SCSI hard drives with HDtoolBox. The first was working, but, I changed my mind a few too many times about how to partition it. After a while, HDtoolBox reported it could no longer read the drive. If INSTALL is performed more than once, will this destroy the drive?
I am not convinced these drives have failed beyond reach. It seems they have corrupted initialization data recorded outside the normal file system area (or in eeprom). Is there a better utility than HDtoolBox for initializing and partitioning on Amiga? How about on another platform (I have some older Macs)?
I followed PFS2 docs carefully when re-partitioning the successful drive. Mask and MaxTransfer (which I know little about) were set to 0xFFFFFFFC and 0xFFFE00, respectively. These are probably conservative settings, but, were one of several options offered in the PFS2 docs. This drive can potentially be moved between A3000s (stock controllers) and A2000s with A2091s. Are these values too small? As suggested, I did the FULL format rather than the QUICK option.
The interesting things happened when I started moving data (with Dopus4) from the corrupted drive to the re-claimed drive. First, if I selected many directories and copied in one go, the process would halt if a corrupted file was encountered. After resetting, I was surprised that none of the data had made it to the destination. This must be a characteristic of atomic file systems, the target files are not valid unless the copy process completes without fault. Lesson: move smaller chunks of data.
The second surprise was that the corrupted file (there were only 3 or 4 of these) would set the destination drive to READ ONLY (This is a safety feature mentioned in the PFS docs). This was corrected with PFS2's DiskValid tool. Sometimes this took 3 passes, a read pass, a FIX pass, and another read to confirm "Disk OK". I made note of the corrupted files and got them from another source.
So far, the recovered drive is working fine. It is about 2/3s full of data.
