Is this truly silent? Do you see any errors in the system logs?
Overall, this does not surprise me, as I have been seeing quite a lot of "non-silent" write errors with firewire drives. There seem to be a number of places where this is documented - not on manufacturer sites - and the general assumption seems to place the known issues in the general category of "if the transfer is too fast, the system will probably not be able to properly handle it."
There is a site that discusses this a bit and has a utility to check for one of the known firewire issues:
I recently sent the following email to the folks at Granite (who use the Oxfords), though am still awaiting a reply:
We have 3 of your external firewire enclosures with removable bays (a total of 7 drives, including the extra trays we've ordered). These are not of the S.M.A.R.T. variety. We also have two external fixed enclosures. All are of the standard 1394-"A" variant. All connected via your FireVue cables, either directly to controllers or via one of our three FireVue 6 port hubs.
Drives used range from One 40G Fujistu 5400RPM, One Maxtor about 80GB 5400RPM, Two 80GB IBM 7200RPM 2MB Cache Drives, One WD 120GB 2GB Cache Drive, and the rest WD 120GB 8MB Cache ("Special Edition Drives). The drives are about half and half FAT32 and NTFS.
Computers used: Two IBM M Pro Intellistation Workstations (Dual 1.8GHz Xeon) with Adaptec 4300 Cards - using either TI or standard drivers, One IBM Single CPU Intellistation with Creative Labs Audigy 1394, One HP/Compaq xw8000 Dual Xeon 3GHz with built-in 1394, One Toshiba Laptop with built-in 1394, One Dell Laptop with Adaptec PCMCIA 1394, Three Tyan Motherboard P4 2.8GHz with both Creative labs Audigy 1394 and Adaptec 4300 Cards - using either TI or standard drivers.
The HP and the Toshiba are XP pro Systems, rest are W2K Pro. All are 100% up to date with OS, drivers, BIOS, and using your utilities, the Granite devices are also flashed to the latest (by the way, I was surprised that even the devices we recently ordered from you were not up to date in the firmware). Etc.
All of the above is mentioned because what I am about to describe happens with 100% repeatability under any and all possible combinations of the hardware above.
What happens? Well, if we use the drives in a "standard" firewire method - e.g., connected not to a computer, but for example to a video device such as any of the Videonics FireStore products, they record and playback perfectly (the FAT32 devices anyway, Videonics does not support NTFS, which is the only reason they are not all NTFS). If we use the drives under more or less "low stress" conditions connected to computers, they also are fine.
If we use the drives under more "high stress" conditions we get the following (example):
"Windows - Delayed Write Failed" Windows was unable to save all of the data for the file \Device\Hardisk\Volume2\$Mft. The data has been list. This error may be caused by a failure of your computer hardware or network connection. Please try to save this file elsewhere.
There is no drive activity at the time of the error - the transfer has aborted. The system at that point is more or less useless - very few actions work, it is nearly impossible even to reboot, even with several HOURS of trying to shut down, close many many instances of these dialogs etc. it always requires a hard boot. To merely click on the fie in question locks the system even after the boot - to remove it you must either delete the directory where it is found or do an "invert select" and hit the delete key.
The high-stress condition that always create the error seems to be BOTH of the following: (1) dealing with larger files (2+GB, often 10-60GB) and (2) the source is fast. For example, trying to copy a 40GB video file off the HP with the source being a Rourke Dual Channel SCSI RAID rated for 4 uncompressed HD video streams. It need not be that extreme - just copying 4GB files off of one of the Tyan system's internal 7200 RPM "Special Edition" IDE drives to the firewire device will also do it. Working at "DV" speeds or less is always fine and error-free, no matter how large the file (e.g., rendering a 40GB file overnight is fine).
The system log records a huge number of "Controller Errors" during these failures.
I have tried, but is seems that it is not possible to disable the write cache on these devices. I un-check the box and click "OK" but when I go back it is still checked.
This is not anti-virus related, as the IBM systems are not-networked dedicated video rendering systems that do not have AV software due to the fact that AV software screws up the video renders.
Any suggestions? Not being able to transfer files to these devices makes them rather limited in their utility, and generally tends to make me view 1394 drives as no-where near ready for prime time (though truly I even tend to think that of IDE).