• Some users have recently had their accounts hijacked. It seems that the now defunct EVGA forums might have compromised your password there and seems many are using the same PW here. We would suggest you UPDATE YOUR PASSWORD and TURN ON 2FA for your account here to further secure it. None of the compromised accounts had 2FA turned on.
    Once you have enabled 2FA, your account will be updated soon to show a badge, letting other members know that you use 2FA to protect your account. This should be beneficial for everyone that uses FSFT.

Hard drive cache.. still a problem?

Doctor X

Weaksauce
Joined
Oct 4, 2004
Messages
69
Greetz!

Remember, it was not too long ago that if you had a harddrive with large cache (or several in a raid), you was in danger of corrupting you drives because when you shutdown your pc, the power would go off before the cache on the drives were flushed. (caught me a couple of times) A workaround which seems to work ok is to turn on Clear pagefile at shutdown... Obviously this has the drawback of greatly slowing down your shutdown.

My question is, is this still a problem? I last time had the problem with XP (no sp) or sp1 .. I cannot remember which. Woudl like to got back to not clearing page file. What is everyone's thoughts on this?

Thanks a bunch!
Doctor X
 
still a concern especially with a parity array
As the Hard Disk Spins series Part II RAID a matter of parity Page 4 @ Lost Circuits

The RAID Cache

Many RAID controllers use substantial amounts of SDRAM to alleviate performance bottlenecks that can arise on writes. That is, the data are not directly written to the drives but to a dedicated memory module or discreet component from which they are then processed and forwarded to the individual drives. The reason is that RAID Level5 or any other level involving parity calculations are notoriously slow when it comes to writing data to the array, moreover, there is a substantial amount of computation involved as we showed above, that can interfere with other system processes

One issue that can arise from RAID cache using SDRAM is that this type of memory is volatile, meaning that in case of a sudden loss of power data that have not yet been written to the platter can be lost. The workaround in this case is relatively simple in that any battery can be used to keep SDRAM in autorefresh mode, which suffices to prevent data loss while running at extremely low power consumption.

Write Hole

Another issue with RAID levels that use parity is the problem of the write hole. The write hole is the time between writing a set of data to one of the drives within the array and the time it takes to update the parity data. In other words, if a loss of power or any other catastrophic system failure occurs after the data have been written to the media but before the parity data have been updated, the result will be that the parity no longer matches the data. For correct storage of data under all conditions, it is therefore necessary to have a record keeping mechanism in place that “journals” the status of all write transactions and, therefore, after e.g. a power loss, will be able to tell that the data are correct and that the parity will need to be updated accordingly. Needless to say that such journal has to be updated with every transaction and further has to retain data independent of any environmental conditions. The latter condition is matched by a number of non-volatile memory solutions, the cheapest of which is Flash memory, which, however, does not meet the endurance requirements. Therefore, other non-volatile memory solutions such as FRAM or nvSRAM with practically unlimited endurance are much better suited, albeit slightly more expensive.

>>see link of > Screenshot from a White Paper on the write hole on the Zzyzx website, illustrating the vulnerable period of time. > and assorted embedded links

many highend RAID cards have their own batteries

also applicable (since most any array will employ SCSI drivers)
XpScsiProblems Storagereview FAQ
Poor SCSI performance when using WinXP, or Win2k with SP3 or later

To cut a long story short, in WinXP MS corrected a bug in Win2k that caused requests to bypass write caching to be ignored. This bug could have caused possible data loss (if the data hadn't been written to the drive and the power went out for example).

Unfortunately the correction of this bug also affects Windows Explorer. In many circumstances, when using SCSI drives, file copies aren't cached, and performance is extremely slow when compared to pre SP3 Win2k. Win2k SP3 and SP4 also have the XP 'problem'.

There is a Microsoft article that goes in to some depth here (cache).

There are a number of 'solutions' depending on your situation.

For Windows 2000, MS released a two part solution. First, a patch is installed to provide what is essentially a 'ignore bypass write caching requests' function. (Note: this patch is included in Win2k SP4). A tool called 'dskcache' is then used to switch on this option on a per-disk level. More on this available here (cache).

For Windows XP, it is rumoured that MS will provide a solution in SP2. Until then, there is a possible solution created by cas, an SR forum member. It is a program called xpcachefilter, which, when installed, filters out the bypass write cache requests on ALL drives. Note that as IDE drives don't support the command to begin with, it has no effect on them. More on this here (cache). It can be downloaded here (cache). Use it at your own risk.

For Windows 2003 Server, under Device Manager->*select drive*->Right click->Properties->Policies tab there is a setting to "enable write caching on the disk", and a further option to "Enable advanced performance". This last option reverts to the behaviour of ignoring bypass write caching requests.

For now, Windows 2003 Server or Windows 2000 SP2 is the best option for SCSI drive users who feel that they need the lost write performance back. Remember though, it only affects applications and benchmarks that request bypassing of the write cache. As mentioned above, this includes the Windows file copy function from Explorer.
 
Thanks! well i guess I have to keep that on now... I dont have a high end card on my server (Rocketraid404) I run raid5 and 0 on there. Thanks for the info!


Doctor X
 
Ive always cleared the pagefile at shutdown as a basic security precaution
Rampant Paranoia 101 (Scroll down a bit)
with the added benefit of keeping fragmentation under control, well at least if your cycling alot
a few members have boxes with a few years uptime :p
 
Back
Top