Click Death will get YOU! Iomega System
Click Death will get YOU!

Though perhaps of interest primarily to "techie types" like me, I felt that publishing what I'm learning about Iomega Drive Systems would be at least somewhat engaging for many people.

The great bulk of Click Death troubles have centered around the ZIP drive, so the Zip drive's technology will be the focus of my study:

Before plowing into the details below, I feel that I should state that from a design and engineering standpoint, I really am quite impressed with what I've found as I've started looking beneath the covers of the Zip drive.

I have certainly not forgotten that you and I are here specifically because something has gone very wrong somewhere. And I know that Iomega has not stepped up to the plate with solutions, and that the community of "Click Death" sufferers is righteously pissed.

But problems notwithstanding, I thought you should know that you have not purchased a pile of junk. I have a significant amount of experience with such things (see my resume), so I hope you'll take some comfort in the knowledge that these are really very well engineered products with a tremendous effort and cleverness expended to insure their reliability. Perhaps it wasn't enough, we'll see when we know what's going wrong.....

The recording surface consists of 1817 tracks per surface on two surfaces with a track density of 2116 tracks per inch. Each surface is divided into four "zones" having differing sector counts and data rates with Zone #1 being outermost and Zone #3 innermost. Zone #1 contains 365 tracks of 72 sectors per track, recorded at 32 Mhz. Zone #2 contains 602 tracks of 60 sectors per track recorded at 26.35 Mhz. Zone #3 contains 469 tracks of 48 sectors per track recorded at 21.76 Mhz. And Zone #3 contains 381 tracks of 40 sectors per track recorded at 18.0 Mhz.
Data are recorded using Constant Density Recording (CDR) (variable frequency) Run Length Limited (RLL) encoding with a fixed frequency servo.
There are a total of 40 spare tracks per surface (80 total), though I don't yet know in which zone they reside, therefore I don't yet have a total spare sector count.
The first two tracks on each surface are special non-customer data "Z-Tracks" which are used for storing the drive's serial number, handling surface defect management, storing a format history, and performing sector write diagnostics. When a cartridge is inserted into the drive, the first track on side 0 is read. If it cannot be read successfully then the first track on side 1 is attempted. If this fails then the second track on side 0 is tried, and finally the second track on side 1. If NONE of these four critical Z-Tracks can be read successfully the drive shuts itself down, only permitting a subset of operations ... and excluding any user-data reading or writing. It may turn out that this is one of the problems we're seeing with completely "dead" disks. Users have reported that performing a destructive format sometimes brings such disks back online. This makes sense since a full destructive "format unit" command is allowed in the face of complete Z-Track failure.
The read/write heads normally operate in a "track following" mode using the track's embedded servo information to stay centered on the current track. However, remaining on one track for an extended time would subject that region to uneven wear. Thus after three seconds of inactivity the heads switch to "sweeping mode" are are slowly swept back and forth across the surface of the disk in order to balance wear across the disk. Then, after three minutes (default) of sweeping, the heads are "parked" and pulled out of contact with the media. Finally, after fifteen minutes the motor is stopped and the drive spins down.
When the heads retract they come to rest on a bit of "head cleaning material" which (supposedly) automatically cleans them. But having carefully performed exploratory surgery upon one of my brand new drives (purchased for this purpose) I am skeptical of this system's effectiveness. For one thing, since there's no place for the accumulated grime and magnetic oxide to "go" -- i.e. no way for it to be removed from the drive as in standard diskette head cleaners -- it seems to me that this cleaning material will eventually accumulate its own supply of dirt, grime, and oxide and lose whatever effectiveness it may have originally had. It's still MUCH too soon to say for sure, but I think that lack of effective head cleaning might be one of the drive's Achilles heels.
The drive's ECC (Error Correction Code) system employs a sophisticated three-way interleaved Reed-Solomon correction algorithm which allows the drive to correct a single huge "burst error" of up to 24 bytes or 192 bits from the first bad to the last bad bit, while also giving it a non-zero chance of correcting two or three smaller error bursts which occuring with a greater bit spacing.
The drive employs on-the-fly defective sector reallocation for both reads and writes. The read error recovery strategy employs the standard approaches (multiple re-reads with and without track position skewing) and a few clever techniques such as "missing ID prediction" which allows the drive to find a sector even when its sector ID field is unreadable since it knows what the neighboring sectors will be.
The drive is formatted from the end toward the beginning, giving the user the maximum amount of time to halt the format and leave the FATs and Root directory intact.
Defective sectors are replaced by new sectors out of a pool of 126 sectors per disk side. This pool is renewed from a larger pool of 1610 sectors per side during either the Iomega Quick or Long format operation.
When all four of the redundant Z-tracks have died the disk cartridge becomes inaccessible. There is currently no known way of recovering from the loss of all four Z-tracks.
The Quick Format marks the field-relocated sectors permanently bad, renews the 126-sectors per side reallocation pools, zeros the FATs and the Root directory.
The Long Format analyzes the surface of the disk using a number of worst-case data patterns to locate weak sectors. When found, spare sectors are allocated from a large pool of 1610 spares per surface. Field defects which would have been marked permanently bad by the Quick Format may be returned to use if the Long Format finds nothing wrong with them. Note that this implies that for maximum data integrity, so long as the 1610 spare sector pool holds out, the Long Format should be AVOIDED as it tends to return sectors to use which were removed from use for some reason. However the Long Format has the benefit of re-writing the sector ID's, which is healthy. Thus the new product I have started designing will offer a NEW safer style of Long Format which will provide both benefits.

Check back here from time to time.
I'll be adding to this page as I learn more ...


Return to the Research Notes Index