>Competition in hard drive manufacturing is brutal, and the drives themselves are commodity items. Makers can't afford to "differentiate" themselves based on poor reliability. All surviving drive manufacturers have extraordinary QC programs in place.
>

There's provision for proactive diagnostics for IDE - S.M.A.R.T. provides for testing and reporting of anticipated failures, so that regions with 'weak' bits are flagged as bad before failures actually noticing them as bad because actual data is lost or damaged, and running self-tests on the disk electronics. The idea is to allow the drive to be replaced or at least backed up when the drive fails. If you have a SMART-capable drive and IDE controller, it makes sense to use the early warning to me, although it may move the heads away from the place read last. Most drives have on-drive buffers that can record lots of tracks in them, and the general logic is to read and buffer data as soon as the heads are positioned, rather than only reading the designated sector - just buffer the sectors read first, which minimizes the effects of latency where data access is localized; it doesn't delay the next request, and if the sectors are subsequently read, there's no latency delay waiting for the data to rotate under the head, and may save you from reseeking the track if the head needed to be repositioned before the 'free' pre-read data is requested.

While QC has gotten better, drives still fail, and IMO, they're more likely to fail on people who power down when their done with it, or who rely on the power-saving features of the OS that 'spin down' a disk after some period of inactivity. Mechanical drive failure is most likely to occur on startup or shutdown. Most drive disaster stories begin "Well, it was OK when I turned it off last night, but when I turned it on this morning..."; reports of funny noises, strange smells, or demands for a boot floppy almost always occur before I've had enough coffee to deal with the problem.

Most of my clients have taken my advice to leave the beasties running - if for no other reason than to allow them to be backed up regularly at night during the night; you can leave the system at the Windows login - both of the backup products I work with can perform backups when no user is logged in as long as the backup client software is running as a service. I leave everything but the laptop here running 24/7, and run backups across the LAN - I'm going to play around with 2K's offline storage using the tape drive at some point. And I regularly save registry and AD images to a Jaz cartridge on the server more often.

The Jaz offers me a big benefit - I can keep a bootable, basic install of each of the boxes here; if I really screw things up, I can move the Jaz drive to all the boxes, connect it via the external SCSI port, and dink with the Adaptec BIOS configuration to use the Jaz using SCSI ID 1 as the boot device (I make sure that ID 1 is left unassigned on each box), put an already-configured basic OS install with the networking and backup client software installed, and use that to recover from crashes using a tape drive living on another system without having to install, and without requiring a reboot during the restore, since the restore is going to a different disk than I'm running the OS with - no worries about having to re-apply SPs or adjust the AD information, since after the backup the system will keep it's original identity.

If you tend to break things, or have concerns about installing a beta product on a production system with lots of apps installed or adjusted, making images and planning for the inevitable need to return to the desired config makes sense to me; I can recover individual files from an image (it's slow, if I need a whole lot of specific files, I can restore the image to a different drive and then getting what I want from that.) Since I make a full backup IAC, image backups won't take much longer, and since I use DAT with hardware compression, I don't particularly care if the tape software compresses image backups - DAT has done LZH compression on the drive ever since DDS-1/DC, and it's probably compressing as well as software-based data compression algorithms will do.

I take backup seriously; it took lots of time toset up everything just the way I like it, so even though it'd be lots faster to just back up what I've added or updated, I'm minimizing the time to recover from catastrophic errors - a drive going down, massively pummelling the reigstry, serious virus effects (ie the MTX problem now, Melissa) or a cow flying by and installing the AOHell product. Images also offer a way to pre-configure some test environments and set the up on my normal systems - image a system completely, and then blow on images of basic test environments as needed - when it's done, restore the image to get the system back to it's normal state.

>As for the OS side of things, MS is making a concerted push into the "big iron" / "mission critical" / "enterprise ready" territory with W2K. They can hardly afford to let a problem with a fairly fundamental I/O driver fester.
>

I don't think anyone considers IDE to be deployed in that environment, other than possibly as a basic boot device. I think IDE will eventually be relegated to removable media like CD and DVD, where overlapping I/O is not an issue; Intel is pushing Firewire, there's tons of very solid SCSI product, both in the LVD U160 market and in FC, with a very loyal following; most high-end backup is SCSI based at this point, and a platform that can deal with legacy hardware going back to the mid-80s without impacting the use of current equipment is retaining users - I have two SCSI-2 Narrow devices here in use - the DAT and the Jaz, and they don't prevent me from getting full performance out of the Fast/Wide, UW and UW2 stuff I use on the same channel (obviously, I've had to deal with the cabling and termination issues, but it's not a big deal.)

>Have you submitted your findings to MS as a bug? You've got the system/hardware chops that they'd probably listen to you... :-)
>

It's been reported to several people, along with my test results; other people have reported the same thing. It's a matter of if the VFP team deals with it, by not somehow updating the directory information prior to the buffer getting flushed, or if MS fixes the ATAPI drive to behave better is anyone's guess.

>>
>>>Question for you: In your testing, were you using machines that not only shut down, but powered off under OS control when shutdown was "complete"? These days, some ATA drives have buffers of 2MB or more, and I'm wondering if the drive is getting powered off before it can fully write its local buffer contents out to disk.
>>

I created the problem by abnormal termination of the machine - Win2K does force a write to disk, and unless there is a whole lot of seeking going on, it should take under a second to write 2MB. Most current drives will move at least 4MB/sec to the platter, with full-stroke seeks taking well under 50ms, and average latency around 8.33ms for a 7200RPM drive. I'm not currently up-to-date on the exact behavior of the newest Ultra ATA specs, but the last I heard, it was not doing any significant I/O scheduling; last I heard, it could defer a write if a read request occurred while a write was pending in it's buffer if the direction of movement of the head would reach it first, and writes were sequential - writes happened in the order that they were received to preserve the state of the media, and writes did not defer if a read required the head to move 'away' from the earliest pending write. I can try to find the ANSI X3T10 web site if you need it, it used to be hosted by NCR, which is no longer a player in the marketplace.

>>I don't think that's the problem.
>
>Just curious - why not?