The great hard drive cache myth

[Adcadet]

I think this topic has strayed slightly from the original post of the danger of a HD cache to HD benchmarking. I'm going to comment of the original issue of the danger of a HD cache.

First a read-only cache is not dangerous at all, because the data is still on the HD if the HD shuts down.

There is a distinct difference between a buffer and a cache. A buffer is sequential (typically first in first out (FIFO)), while a cache is non-sequential. Since we are only dealing with writes then we are basicly dealing with in-order delayed writing (buffer) vs. re-ordered elevator seeking.

Buffers are safer than caches when power is removed. The best example I can give you is dealing with directories/fats/files. Suppose the cache elevator seeked and wrote out the data in the following order of fat table, directory table, followed by file data. Then if the drive failes inbetween the fat table and the directory table then there will be file system corruption: The fat points to garbage. If the drive fails between the directory table and the file data then there will be data corruption.

However, if the drive is buffer driven then everything will be written out in the correct order - File data first, next the directory entry, followed by fat table. If the drive failes at any point before the fat table data has been written, then the most that can occur is that there is no file/directory only lost clusters. This is assuming that the OS is designed for this type of failure and all versions of DOS and Windows have been in the past.

The same effect can be shown even with a journaling file system. Elevator write caches can corrupt even a journaling file system because the log can be updated before the data was written causing possible corruption upon power loss. If the drives use buffers then everything gets written out in the correct order and thus the file system can be corrected incase of power failure.

I am unsure about NT/2000/XP's elevator seeking and how it operates to prevent file system corruption. My best guess is that there are certain files/locations that the OS will not elevator seek so as to protect the file system integrety.

This is why HD's have write-buffers rather than write-caches and why they are relatively safe even when the power has been interrupted.

So when we are talking about SCSI's read/write optimizations, command queing, etc, we aren't at all talking about recorganization of the commands in a buffer but rather in the SCSI hardware. Correct?

 

[Platform]

..··

OK, now you've gone and pushed one of my buttons.

Well, well, my fine feathered friend. It's not like I used to take the occasional dummkopf over at the old SR about this very topic; during the 1999~2000 period -- I gave up after this period. The arguments were always centered around CD-R/W drives' write buffers, though.

"Oh no dude, you mean CACHE, dude." Ahhh, I give up.

..··

 

[P5-133XL]

So when we are talking about SCSI's read/write optimizations, command queing, etc, we aren't at all talking about recorganization of the commands in a buffer but rather in the SCSI hardware. Correct?

No, not really. All the SCSI read/write optimizations and command queuing are is an API: If you give it certain commands it expects certain behavior. All SCSI commands and data will go through several layers of manipulation before it is actually deposited onto the HD. Example layers are The device driver, the Host adapter, The SCSI device interface card, the HD circuitry. In what layer that cache exists does not really matter in regards to the risk to the data.

.