Disabling Flush-Drive-Cache: Is it bad?

[rtool]

I've installed a Maxtor 200GB 8mb drive thanks to the hot deals. (not RAID, just a single drive)
Since my motherboard (Dell) doesn't support ATA/133, I installed the included ATA/133 PCI adapter just for the heck of it.

Not having run any benchmark, I haven't really gauged the performance or anything. But I noticed some stuttering when playing mp3's and avi's.

I strolled over to Maxtor's site and found their updated driver for the adapter; it also came with a note about disabling flush-drive-cache.

Promise UDMA ultra controller driver version 2.0.0050.36 may display poor performance results when using certain benchmark utilities. This is due to an added data integrity feature which allows Window's to issue a flush cache command when the Master File Table is updated. The cache flushing feature ensures increased data integrity across all operating ranges. Previous versions of the Promise drivers ignored the flush cache command until system power down.

WHQL certified driver version 2.0.0050.42 allows the cache function to be enabled or disabled via a check box in the Window's device manager. The cache flush option is enabled by default during install and can be disabled during benchmark testing. Maxtor recommends that the cache flush option be re-enabled after testing to insure the highest of data integrity. Typical desktop users will not notice any performance degradation during normal computer use. The latest driver can be downloaded from the Product Support Download Page.

Well, the stuttering seems to have disappeared after disabling that function.

Here I'm left wondering:
a) Am I at risk of compromising data integrity?
b) Am I not taking full advantage of the 8mb cache?

Hope I'm asking the right questions. Thanks in advance to whoever sheds some light.

 

[Lord Evermore]

It doesn't cause you to not take full advantage of the large cache. Normally the cache accepts data writes from Windows and will delay the write to the physical drive until the OS isn't reading any data. If it didn't delay the write, the hard drive would have to stop reading, write the data, then go back to retrieving the data the OS needed. When Windows issues the Flush Cache command when updating the MFT, it's trying to avoid the possibility of the MFT losing data. If the drive lost power or the system rebooted suddenly, before the cache was flushed, the MFT wouldn't be updated properly. However, flushing the cache reduces performance slightly because the drive has to change actions to write the data. The MFT is the primary important thing on the drive, more important than a simple data write since the MFT being corrupted would mean losing entire files, so the flush cache is only done for the MFT and not for every file. So the drive's cache is still used for almost everything. However if the MFT is updated a lot, then that means the cache gets flushed a lot and the drive loses performance a lot.

If you disable the function, then the Promise controller ignores the flush cache command. If your system is stable and doesn't reboot or crash, then this shouldn't cause you any data loss, but it does leave it open to the chance of lost MFT updates. When the function enabled, the Promise controller will accept the command and empty the drive cache whenever Windows says to.

If your Dell board does support ATA100, you would probably be perfectly fine using that. No drive can really take advantage of the 133MBps bandwidth of ATA133. As long as the Dell BIOS supports 48-bit addressing, it will work fine with the large hard drive. Most recent boards do support this, or can with a BIOS update.

 

[zephyrprime]

Wait a second, so do you get stuttering with or without flushing? Interestingly, this seems like is something like the immediate metadata writing problem/thing with XP and scsi drives.

Also, not everyone thinks that Windows' metadata writing policies are a good idea. I read a short critique of them by Linus Torwolds (sp?)

 

[Lord Evermore]

Torvalds.

He's disabling the cache from what I can understand. I think perhaps with the previous driver version, Windows tried to issue the command, but the Promise controller ignored it, and that caused a performance drop. Now with the new drivers, when you disable it, it stops Windows from trying to issue the command entirely, and when you enable it, it makes the controller honor the command. Best I can tell, it was the fact that Windows was trying to issue it and the controller was ignoring it that caused the performance problem, not the caching function itself.

rtool, did you try benchmarking with the cache function enabled in the new drivers, or did you just boot up and disable it? It may be that now, when it's enabled, the stuttering will go away too because the controllers isn't ignoring the command, which maybe confuzzled Windows.

 

[rtool]

Thanks for the replies.

Yes, I have flush cache disabled (on my Promise card) right now and the stuttering has disappeared entirely.

I haven't benchmarked it before/after disabling, I guess I should have to get a definitive answer.
Anyway, I'm thinking of switching back to just the ATA/100 support on my Dell since, like you've said, I probably aren't gaining much from the ATA/133 anyway.

 

[zephyrprime]

I think perhaps with the previous driver version, Windows tried to issue the command, but the Promise controller ignored it, and that caused a performance drop

I think you're reading it wrong. In the previous driver version, the promise drivers always heeded the flush command and now the new driver has the option to ignore the command.

 

[Lord Evermore]

Dunno. Let's read it again:

Previous versions of the Promise drivers ignored the flush cache command until system power down.

Nope, I think I got it right.

 

[rtool]

Yikes, now I can't uninstall the Promise card. :frown: I plugged the IDE cable back into the IDE connector on the board, removed the Promise card, but WinXP just gives me a BSOD during startup and restarts on its own (even in Safe Mode); it all happens so quickly I can't even read what the error code is.

I've updated my BIOS and enabled 48-bit addressing in WinXP as per this Knowledge Base article
I've also tried uninstalling the Promise card from Device Manager before physically unplugging/reconnecting stuff...

I've e-mailed Maxtor support about uninstalling the Promise card...but I'm not holding my breath...

Do you have any insights (hopefully anything short of reinstalling WinXP)? Thanks in advance