No, I never uninstalled to see if that made the problem go away. Never even considered until now.

My problem was solved by removing the 250GB drive from the USB2 enclosure and installing it internally, via IDE. I placed a smaller 40GB drive in the enclosure and have not had the problem since, touch wood.

Jeff - do you think it was caused by the large size of the 250Gb drive or something else then?

Just my two cents: hooked up a Maxtor 5A300J0 300 gig drive as secondary slave to my win2k Gigabyte 7N400 Pro mobo and got the same delayed blahblah. Changed the speed in the nVidia IDE driver (Control Panel) from UDMA 6 (ATA133) to UDMA 5 (ATA100) (kept write cache enabled) and the error messages magically disappeared. Oh the joys of Billy Gatez quality product...

Hi,

I had the same problem. Actually, there is another topic on this issue on this same site which helped solving this. For me, the solution was to lower the IDE bus speed from UDMA 6 to a lower rate (say, UDMA 2). Try experimenting with the IDE speed and find the highest value that still does not cause disk errors/warnings to appear in the Event Viewer. Also look for disk event type 50s (paging operation error), which also tend to disappear at lower IDE speeds.
Note that you need to do some "heavy" disk operations to check if your system works correctly (i.e. copying several GBs of data).
And as soon as you find the proper settings for correct operation, don't forget to format your problem hard disks (these errors tend to corrupt the directory structure which later on can cause data loss).

I hope this will help you as well. Anyway, it does not do any harm, so why not give it a try.

Have a nice day!

M.

Ok, here was the problem with my delayed write failed problem.....


I have 2 external firewire MAXTOR drives (60GB and 120GB)

XP (surprise) doesn't automatically (at least on my machine) generate a pagefile for separate hard drives. Go into CONTROL PANEL - SYSTEM - ADVANCED - PERFORMANCE - ADVANCED - VIRTUAL MEMORY CHANGE AND ADD CUSTOM VIRTUAL MEMORY FOR EACH DRIVE (PROBABLY ABOUT DOUBLE YOUR RAM WOULD BE A GOOD STARTING POINT). BE SURE TO PRESS "SET" AFTER EACH NEW SETTING YOU MAKE FOR EACH DRIVE.


Hope this helps....

>>>>>>>>>SOLUTION<<<<<<<

Your HD probably doesnt have a pagefile.

Give EACH HD a pagefile. Be sure to press SET after you have set one or it won't hold.


Hope this helps....

Don

Very interetsing, I'm going to check my pagefile settings as soon as I get home tonight. I haven't had the failure in some time but am always concerned when I start copying my "new" programs to the external drive.

I'll let you know.

Cheers.

Folks, 2 issues to submit:
1. Does anyone know how to force Maxtor Ultra ATA 133 controller to allow the UDMA hard-dosk to run at reduced speed, say UDMA 5 or 4. I have not been able to find any technique on the MAxtor website.

2. I also thought I'd pass on something I was told by a knowledgeable Microsoft support engineer. He suggested I do NOT keep the pagefile on more than one disk. He recommended keeping ONEpagefile in its own dedicated partition (any NTFS partition), and to keep it slightly SMALLER than the size of Physical RAM, if I wanted to increase the O/S (Windows XP Pro) usage of RAM (and reduce the paging to disk).
I had registry corruption problems (unrelated to the Delayed Write Failed), and he said that when Windows XP pages to disk, the registry and part of the O/S working data do not necessarily get paged all together in the same partition. THis could cause the registry to get corrupted. In may case, after I switched to a single pagefile on 1 fast disk, all the corruption problems stopped.
I must say that I have been able to "stripe" the pagefile over 2 or 3 disk-drives and /or partitions in the past (with Windows NT 4) without problems. Even with Windows 2000, I was able to split the pagefile for systems which were not heavily used. But with heavily used systems (i.e. saving many files to disk, reading and writing, etc), both Windows 2000 and Windows XP had corrupted disk-partition tables (in one case even the MFT got corrupted), and I fear that one of the contributing factors was a split pagefile, the other one might have been disk-fragmentation. I had to reformat the disk, because even restoring a saved copy of Partition table & MBR did not fully recover all the files.

Just thought I'd add my 2 cents worth, even if the Delayed write Problem is not related to Point # 2 above.
Suren

I'm not really keen on putting a swapfile on my external hard disk. If I do this, wouldn't it mean that I wouldn't be able to hot-swap the external hd as needed? Especially since some of the pagefile currently being used may be on that external hd so when I try and disconnect the external hd, I'm assuming that Windows won't let me, since it's still using the pagefile

This might be on interest to people with "delayed Write failure" problems (http://www.bustrace.com/products/delayedwrite.htm)

Delayed Write Failures with 1394/FireWire Drives
Do you own a 1394/FireWire drive and are experiencing "Delayed Write Failures" under Windows 2000 or Windows XP? Do you experience data loss and/or a hard drive lockup when this occurs? If so, read on to learn the similar frustrations one of our developers has experienced.

I own two 1394 hard drives. One is a SmartDisk FireLite 20GB drive while the other is an ATA drive I inserted into an ADS Technologies PYRO 1394 Drive Kit. I use the SmartDisk drive extensively. I purchased it to replace an older model SmartDisk 20GB drive. When experiencing heavy disk activity, at seemingly random times, my drive would lock up and I would get that annoying "Delayed Write Failure" as reported by Windows 2000 and Windows XP. The drive was locked up solid. I would either need to disconnect and reconnect it from the bus or, more typically, I would simply reboot my system. As you can imagine, such a failure can and did result in data loss for me.

With my original SmartDisk drive, this would happen very infrequently. I learned to live with it. With my newer SmartDisk drive, it happened several times a day. Thinking it was a problem just with SmartDisk, I took my reliable ATA drive, placed it into the ADS Technologies box, and tried that. To my surprise, I received the EXACT "Delayed Write Failure".

I was ready to write off 1394 hard drives as being just plain flaky and unreliable and not reliable enough to trust my data. I researched several 1394 drive vendors' WEB sites and some did mention this problem, but they had no idea what was causing it.

Having spent my hard earned money on these drives, I decided to dig deeper and determine the root cause of the failure. Fortunately, I own busTRACE 2003 so I was able to capture and analyze the I/O activity going on between my Windows PC and my 1394 hard drive. I started a capture sequence and ran a software app that would often cause this type of drive failure to occur. After a few minutes of trying, I captured the error!

I looked at the specific I/O that was failing and I noticed that Windows was attempting to write out 3FFh sectors (1023 sectors) in a single I/O. This is approximately 512K worth of data in a single I/O. I thought this was interesting as Windows typically does not send an I/O larger than 64K and very rarely above 128K. The I/O eventually timed out but the drive was now "hung" and further communication with the drive was impossible. Windows was left in a state of needing to read/write to the drive, but it couldn't. When Windows cannot flush its buffers, it reports the "Delayed Write Failure" telling you that data may be lost.

512K worth of data in a single I/O was a clue so I wrote a special test app that would read/write starting with 1 sector and keep going up until 1024 sectors. I wanted to find out where the failure boundary was. As it turns out, both of my 1394 drives would crash when the request was larger than 128K. In digging a little deeper, and in talking to various people, this seems to be a known limitation with some (not all!!!) 1394 bridge chips. I was told that a firmware upgrade might/should resolve it.

I searched long and hard for any firmware updates to my SmartDisk and ADS Technologies drives but I couldn't find any. If you know of any such updates, I encourage you to contact me so that I can update this WEB site with that link information. Determined to fix this problem, and get confidence back in 1394 hard drives, I decided to write my own little filter driver to limit I/Os to no larger than 128K.

What has been the result of my driver? Well, in several months of running my SmartDisk drive, I have not seen that Delayed Write Failure again. If you're seeing this failure as well, it is highly likely that you are experiencing the same problem I did.

What can you do to resolve this in your case? For one, contact your drive vendor. They are the ones that should come up with a resolution for you. If they have heard of the problem before, but do not know the root cause, point them to this WEB site. I have described in detail exactly what the problem is. If they have a driver writer on staff, they should be able to easily generate a driver to resolve the problem.

If you are a drive vendor reading this, and if you don't have such an engineer (or if they're busy on other tasks), please contact us at busTRACE Technologies. Our 1394 driver fix is currently only for internal use. However, if you are interested in a royalty free distribution license, we can polish it up for end-user distribution and sell it to you.

I put a swapfile on my external HDs since they are pretty much always on and attached to the same comp.

To ghostdunks ghostdunks:

Interesting post, let's hope MS or the hard disk vendors can get their collective arses in gear and fix this without all of us having to resort to buying your commercial solution.

One question however; does the same error/solution apply to USB 2.0 drives? I have/had a Western Digital 200GB external firewire/USB 2.0 hard drive that consistently had these problems in both firewire and USB state (never in USB 1.0 though!) I eventually gave up and pulled the drive from the case and installed it internally, and substituted a smaller 40GB Maxtor in its place. I have not had the problem since.

So, not to ramble, is the same error error likely to occur with USB 2.0 connections?

Again, great post, at least someone was able to "identify" the problem.

Cheers.

I wish I had access to a solution, commercial or otherwise, this problem is that frustrating. All I did was find the page on the BusTrace website that mentioned the problem. I've actually emailed them regarding whether they can release the testing tool they used to identify the error, and they replied saying that they might release it on their website soon after they've cleaned it up. If we're really nice to them, maybe they'll actually release their filter driver which supposedly fixes this, and we can all go to sleep feeling good

I've also emailed both manufacturers of my enclosures(both with Oxford 911 chipset), telling them about my problem, and pointing them to the Bustrace page to see if they can make up a fix. As they are both in China/Taiwan, I doubt whether they'll give much support. I would encourage everyone else to do the same to the manufacturers of their enclosures, and maybe we can get some resolutions

If a fix doesn't appear soon, I'm thinking of writing the fix filter driver myself and releasing to the general public as it seems like this problem is quite common. But after doing research on writing drivers for Windows XP, I doubt I can do this as it requires a fair bit of in-depth knowledge. Any super-elite programmers out there willing to try this?

I too have heard that if the large drive in the external enclosure(large meaning 120 gb and over) is substituted with a smaller drive, this problem disappears. Maybe Windows only tries to send big I/O requests when the hd is big?? who knows...

I myself have had the error with the USB2 connection, but I'm not sure if it's my dodgy no-name USB2 PCMCIA card that's causing it.

Ok, have done a bit more research into this problem. According to the writer of the article(http://www.bustrace.com/products/delayedwrite.htm), the problem occurs generally when a single I/O request is made to the drive that is larger than 128k(which presumably is over 256 sectors??)

After doing more research on this, I found this extract from the Windows XP DDK:

"the system AT disk driver must split up transfer requests for more than 256 sectors due to the disk controller’s limitations"

So it looks like AT hard disk controllers can't handle transfer requests that are larger than 256 sectors(ie. 128k). Can anyone else confirm if this is true?

I also found something else that was interesting(http://cvs.sourceforge.net/viewcvs.py/linuxsh/kernel/drivers/i....c?rev=1.3), which is some Linux source code for the SBP2 driver, where it mentions that they have to code around "sbp2 devices that do not support individual transfers of greater than 128KB in size". So it looks like they've known about the problem in Linux for awhile,or have at least coded around it.

So maybe the generic SBP2 bus driver in Windows XP doesn't take into account sbp2(ie. firewire, in our case) devices that do not support individual IOs of greater than 128kb in size.

This is the theoretical trail for me. As far as I can tell, the SBP2 driver in XP doesn't know about this limit, so sends out IOs which are bigger than 128kb to the external enclosure. The external enclosure in my case uses the Oxford 911 chipset which just translates the firewire bus request into an IDE ATA request which it then passes on to the actual hd controller. As the hd controller itself cannot handle requests for more than 128kb(> 256 sectors), it doesn't respond properly, so hence we get the error in Windows XP. Can anyone tell me if they think I'm climbing up the wrong tree here?

If my theory is right, then we've got two possible fixes for this. First fix is to tell Windows to not send individual IOs larger than 128kb, which is what the bustrace writer has done by creating a filter. The same principle is also used in the Linux SBP2 driver. The second fix would be to fix the firmware on the Oxford 911 chipset so that it will split requests that are too large into smaller chunks.

Please note that the delayed write failure error can appear for any number of reasons. I myself have encountered the error because of a dodgy power supply switch on the enclosure AND a hard disk that was going to pieces slowly. However, I'm convinced that after all is said and done, and assuming that everything else is working OK, that this large IO request size problem is an underlying problem that will appear sooner or later on the affected firewire bridge chipsets.

Over the weekend, I also tried two other suggested methods of fixing this problem. First one was to put a page file on the external hd. This one I wasn't much in favour of because it would mean I wouldn't be able to hotswap it on and off, but I was desperate. Put a big pagefile on the drive and ran my tests which usually recreates the error, and this time, it even came up with a blue screen which forced me to reboot the entire computer. So, dropped that idea big time. Second idea was to play around with the PCI latency settings using Powerstrip. No dice here either, as I still got the error even after I set the PCI latency on the Firewire bus to 248. So yes, still waiting for a fix.

I managed to find a fix for my problem. See this thread for details if interested(http://www.hardwareanalysis.com/content/topic/13302/)

As of Dec 2, 2003, VIA has released Hyperion 4in1 4.51 to address this issue.
http://www.viaarena.com/?PageID=300

Cheers,

Cerian

Cerian,

Where do you see an article or update history that shows that this issue has been addressed?

I did not see it in the downloaded file or on the link you provided.

Thanks for futher information. I don't have the VIA chipset, but if VIA was able to fix it, then maybe Intel and Microsoft can fix it too.

In the release notes (http://downloads.viaarena.com/drivers/4in1/Hyperion451_4in1release.doc), you'll see:

ViaHyperion 4in1451v.zip 2003/12/01 4.51 2.00a 4.42b 1.20 1.3a 1. Fixed the issue of the Delayed Write Failed only for special condition .
Note: Please install 4in1 4.51 on safe mode if the issue happened.

Glad I use an Athlon, this might help; but ......

why is that the only entry that is written as if it's been spoken by a NYC cab driver? It doesn't make a lot of sense to me. Anybpdy else understand what they mean install in Safe?

No offense to any NYC hacks that "might" end up reading this post.

Cheers.

My wife, who is Chinese, used to speak like that.
They assume that the computer may be too unstable to apply the patch in normal mode.
Follow the instructions for the version of Windows you are using to get in to Safe Mode.
On Win98se, you keep the Ctrl key held down while the computer is booting. Just after the beep you will be presented with a menu of boot choices.

I don't normally monitor this forum, so I probably won't respond further.

Cheers

Cerian Knight