In the last post, I documented the haul of gear donated by a generous reader. In this post, I take the time to see if I can make things better, do some experiments on the Zip ecosystem and report on the results.
Zip 250 USB Teardown
When I encounter a Zip drive that isn’t particularly co-operative, the first thing I think of is to clean the heads. This can be done with a head cleaning cartridge, but as they are exceedingly rare, my go-to method is just to disassemble the drive. To actually clean the heads, undo the springs that provide the auto-parking force for the heads, fold a scrap of clean paper, saturate it in high purity ethanol, manually load the heads onto the paper and gently move the paper from side to side before retracting the heads.
The big challenge was to open the unit. As it turns out, there are no screws holding the exterior casing together – a thin piece of wire in the strategically located holes pushes the latches apart allowing the casing to come apart.
The unit is very tightly put together – the drive and controller PCB are secured to the rear case simply by a piece of plastic and two screws. After removing these, it’s still a struggle to slide it out of the casing – the side grips sustained slight damage as a result.
Unfortunately for me, even with the drive assembly freed, I had no access to the drive heads.
It seems the drive has been designed without serviceability in mind – mainly for cost reduction. The top shield cover is spot-welded along the edges to the base, making it difficult to remove without damaging it and almost impossible to reinstall. As a result, I had to abort my disassembly at this point.
That being said, the underside of the drive does have an amazing array of test points and a few alignment holes. The rear PCMCIA cable connector and USB socket also seems to be hand soldered.
I decided that the only way to clean it might well be to sacrifice a ZIP-100 cartridge by removing the media and replacing it with a fixed sheet of paper that covers the area where the heads insert into the cartridge. That way the drive should load the heads onto the paper, seek back and forth a little and give up. But seeing as I didn’t want to sacrifice a disk … I decided to leave it for now and reassembled the drive to no change in performance.
Supplied Zip 100 Cartridges
I turned my attention to the supplied Zip 100 cartridges just to see if they were readable. To do this required me to go to my recovery box which hadn’t been used since the move. The first thing I had to fix was a flat CMOS battery, then a loose SATA cable, then a ZIP 100 drive with dirty heads, then a broken Windows 2000 install. It was worth it though.
Rather surprisingly, I had problems with them no matter which drive of mine I used, even though my own cartridges written on the ATAPI drive read just fine on all of the drives.
I started with the Zip Tools cartridge and tried to get a read on any of the drives. No dice. Admitting defeat, I decided to see what would happen if I tried to format the cartridge. Using sg_format in Linux, I encountered this error with the ATAPI Zip 100 drive:
This seems to imply something may have gone wrong with the low-level format of the disk which may not be recoverable. Putting the same disk into the ATAPI Zip 250 drive seemed to go a little further as the size of the disk was correctly detected but I couldn’t format it either:
This time, it said it was write protected but I didn’t believe that. That’s when I remembered that Zip 250 drives cannot long format Zip 100 cartridges due to their different head widths. They can’t even write to Zip 100 cartridges at “full speed”.
I decided to check with Windows as IomegaWare might be able to tell me more. On the ATAPI Zip 100, it really was unknown and giving “strange” values.
On the ATAPI Zip 250, it managed to identify some information but the format is unknown and it claims to recommend a long format meaning the data is basically in danger.
Trying a long format on the Zip 250 results in the expected error –
… so I tried to format it in the ATAPI Zip 100 … but …it didn’t work either. This sounds like a disk with a damaged Z-track which might become a cleaning disk sooner or later. But I gave it another shot – this time with the PocketZIP 100.
That drive was able to identify the disk like the Zip 250 drive, but best of all, it actually began to format the disk.
At the end, it failed to set the volume label and the disk was in limbo with an Unknown PC Format.But once I stuffed it back into the ATAPI Zip 100 drive, I was able to format it completely and bring it to health. The disk has been saved! As a result, I suspect that the disks themselves are fine but either the recording on them was dodgy due to a wonky drive or due to poor storage and the passage of time.
Zip 100 & Zip 250 Cross-System Benchmarks
This naturally leads to the question – what is the performance like with native Zip 100 drive + Zip 100 disk versus a Zip 250 drive + Zip 100 disk combination and how does the Zip 250 performance compare to Zip 100 performance. Having previously established the the ATAPI drives are practically as good as you can get, I decided to run the tests on the recovery box which has an ATAPI Zip 250 as master and ATAPI Zip 100 as slave on the onboard Intel 945GC chipset IDE controller.
Zip 100 drive + Zip 100 media
The baseline for our test is Zip 100 drive with Zip 100 media. Read performance averages about 1MB/s with performance varying from 0.7MB/s to 1.4MB/s. Write performance averages about 1MB/s with performance varying between 0.7MB/s to 1.1MB/s.
Zip 250 drive + Zip 250 media
This test was done with Disk #4 (see next section) which had a high media quality according to Iomega’s tools. This provided an average read of 1.7MB/s ranging between 1.1MB/s to 2.3MB/s. Writes averaged 1.1MB/s, ranging between 0.4MB/s to 1.4MB/s. As some of the dips seem to be media related, I decided to try again with Disk #5 which also had high media quality.
Aside from the loss of dips, the performance was still much the same. It seems that the drive retains the side-zero first followed by side-one approach of recording as the Zip 100 but now has more zones and increased speed due to increased density. Access times are very similar, although slightly slower, but the drive is much lighter on CPU usage possibly due to DMA support. Writing on the innermost zone seems to be the biggest bottleneck on the Zip 250 system.
Zip 250 drive + Zip 100 media
While backward compatibility was one of the big selling points to the Zip 250 system, this compatibility is not complete and comes at a cost. As discovered earlier, the Zip 250 drive is unable to long format Zip 100 cartridges. Here, we can see that while the Zip 250 is equally fast when reading Zip 100 disks, it is significantly slower than the Zip 100 when writing to the cartridges. It only achieved an average of 0.2MB/s write ranging between 0.1MB/s to 0.2MB/s. It’s so slow that this tool doesn’t give us a good accurate measure, but we can infer that it is approximately five times slower.
The reason behind this is likely due to the head geometry which is optimised for thinner tracks used in the Zip 250, resulting in the write process being a complex multi-pass process to ensure the old “wide” track is properly fully erased and writing adequate signal in return to ensure interchangeability. Indeed, I found that Zip 100 disks written by the Zip 250 were readable in the Zip 100 drives.
Zip 250 Defect List Analysis
Compared to Zip 100 disks, my experience with Zip 250 disks recently seems to show that they are more troublesome when it comes to data recovery and less reliable. Whereas the Zip 100 seemed almost bulletproof, I am yet to come across a Zip 250 with its original data that would read through without having to go through a long multiple-retry process.
As a result of an earlier discovery that I could read out the ZIP disk defect lists using sginfo and some debate about how or if this correlates to the IomegaWare reported media life and format life, I thought this would be a good time to put that to the test. I grabbed all six ZIP250 disks, recovered as much data as possible, then put them through a long format. Then I read out the defect list and the relevant data through the IomegaWare properties.
At a glance, we can see:
- The PLIST defect data usually has no invalid tracks in it from the six disks formatted. The GLIST data can have invalid tracks.
- The Iomega Media Life and Format Life values do not correlate with the total entries in either PLIST or GLIST. In fact, Disk #4 I used for testing due to the high media and format life has the highest defect list total, whereas Disk #5 which I also used in testing has the lowest defect list total.
- Despite a lack of correlation, the PLIST and GLIST data seems to be accurate if judging from the throughput from HDTune in the previous section – Disk #4 exhibited a large number of throughput dips compared to Disk #5 despite both disks having the same Iomega Life values.
- I suspect the Iomega Life parameters also counts pending/weak sectors and possibly has other metrics about the media signal response to weigh in on its reported value. It may also be related to how many times the cartridge has been formatted, how much reading/writing it has endured, the time spent with heads loaded – I have no idea exactly what metrics are used. However, whether the Iomega metrics are more accurate is not certain either.
- The cartridges have a manufacture date ranging from Day 330 in 1999 through to Day 64 of 2002.
I decided to go further and graph the defect lists to determine whether they could be plausible – they return consistent data as established prior, but does the spatial characteristics of defects suggest that the data is reliable?
With the defect data from all six disks overlaid, we can see that the physical geometry has >= 2843 cylinders (highest observed value), with each cylinder having two heads and >= 119 sectors in each track (highest observed value). The highest value for sectors decreases as a function of track number, which validates that a multi-zoned recording strategy is being used, consistent with throughput graph information. Some clustering can be seen which suggests that the defect data is genuine.
Disk 1 seems to have most of its defects in localised areas on Head 0 with random locations for Head 1. The localised areas display a different straight line “walk” from cylinder to cylinder, which suggests these are radial defects but due to the offset skew of which sector is 0 from cylinder to cylinder, this causes the defects to appear as if they are “moving” up or down. The “walk” pattern is different in different zones, which is expected due to the different sectors per track.
Disk 2 shows similar behaviour, although the localized defect patches are more towards the inside radius. So far there is no correlation between errors across sides of the disk, which is expected of manufacturing problems whereas physical damage would show correlation.
Disk 3 shows a stationary pattern around cylinder 1600 – this may be an indication that at that point there are four defect points equally spaced in a revolution and the skew is exactly a multiple of 1/4 revolution. So far, all defect regions seem to exhibit a periodicity of four per revolution, so maybe some of these defects are not truly defects but a problem with servo positioning data depending on how it is laid out.
The most defective disk of the bunch shows a reversed trend where the surface for Head 1 is definitely more defective. This also helps us validate the data as being probably genuine.
The least defective disk with only two patches, but mostly on Head 1.
Tearing down the Zip 250 USB drive was not particularly productive as it was not designed to be repaired or serviced, making it impossible to manually clean the heads. Maybe I could attempt doing so with a modified/sacrificed Zip 100 cartridge in the future.
The Zip 250 system is faster than the Zip 100 system using their own respective media, achieving average read of 1.7MB/s versus 1.0MB/s. However, the Zip 250’s write speed takes a hit, especially in the inner zone, averaging 1.1MB/s, practically identical to the 1.0MB/s of the Zip 100. While the Zip 250 drive has backward compatibility, it comes at the cost of not being able to long format Zip 100 disks and being about five times slower to write to Zip 100 cartridges.
It was found that the defect lists from sginfo did not correlate with the reported readings from IomegaWare in terms of Media Life and Format Life. It is possible that the IomegaWare values take into account other parameters not exposed, however, this is not to say that the defect lists reported by sginfo are useless.
In fact, the defect lists reported by sginfo seems plausible based on error distribution – they correlate with increased read/write throughput disturbances, their spatial distribution clusters spatially and “walks” due to cylinder skew as expected, the maximum sector number decreases as a function of cylinder number as expected with a multi-zone recording system and the most-errored-side is exactly a 50/50 split in the sample of six disks. The errors also have a periodicity of four errors per revolution, which may indicate something about the servo design of the Zip system and it seems that the PLIST never has any defective whole-tracks.
In all, another fascinating experiment made possible by a kind reader. Thanks!