Not able to disable disk write cache
BruceKrautbauer
disable the hard disk write cache to help reduce corrupt disk writes in the
event the user powers off the system (we have no control on power off and do
not have any battery backup capability). We have used the control panel –
system – hardware – disk drives – properties – and unchecked the “Enable
write caching on the disk” setting. However, files are being written as if
the disk cache is still enabled. We have seen the disk writes take up to 14
seconds on FAT32 file system and about 3 seconds to actually get written to
disk. We have also tried to use the DISKCACHE.EXE tool with the same results.
Is the disabling of disk cache setting not working with XP Embedded? Is
there a workaround that can be used to enforce this or could there be a
component missing that is needed to make this work?
Thanks!
Slobodan Brcin (eMVP)
You will have to switch to "optimize for quick removal". (If you can't then you will have to force it in registry)
Regards,
Slobodan
"BruceKrautbauer" <mdtc...@newsgroup.nospam> wrote in message news:CAD60034-6E68-46BE...@microsoft.com...
> Our system is running XP Embedded with Service Pack 1. We have attempted to
> disable the hard disk write cache to help reduce corrupt disk writes in the
> event the user powers off the system (we have no control on power off and do
> not have any battery backup capability). We have used the control panel -
> system - hardware - disk drives - properties - and unchecked the "Enable
BruceKrautbauer
"Optimize for quick removal" is disabled for this drive (it is not a
removable drive).
How can we force this in the registry?
Thanks,
Bruce
Slobodan Brcin (eMVP)
The easiest (hack) way would be to modify disk.inf.
But for test purposes find in registry values under Device Parameters\Classpnp\UserRemovalPolicy set it to dword 3.
This will be somewhere like:
HKLM\System\CurrentControlSet\Enum\.....\Device Parameters\Classpnp\UserRemovalPolicy
Use regmon to find exact position.
Regards,
Slobodan
"BruceKrautbauer" <mdtc...@newsgroup.nospam> wrote in message news:375BA304-24DF-4034...@microsoft.com...
bde...@init-ka.de
I also have problems with write caching and tried your registry patch,
but without success.
Can you give me some details about the "hack" solution? (modify
disk.inf)
Thanks,
Bernhard
Slobodan Brcin (eMVP)
If you can't make it work trough registry then inf file will not do you any good :-(
I assume that you used regedit for finding and setting value in registry, right?
Have you restarted computer after the change?
Also make sure that value remained unchanged.
Regards,
Slobodan
<bde...@init-ka.de> wrote in message news:1104164962.4...@f14g2000cwb.googlegroups.com...
bde...@init-ka.de
yes, I used regedit, restarted the computer, and the value remained
unchanged.
Here is how the regedit export looks like:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\IDE\DiskSanDisk_SDCFBI-256______________________HDC_2.13\4&6cb4d8c&0&0.0.0\Device
Parameters\Classpnp]
"UserRemovalPolicy"=dword:00000003
When I test with a USB stick with activated "optimize for quick
removal"
switch, there are no problems with sudden power off.
But for the compact flash card (and here I need this feature!),
tests show that files get corrupted, even with the above registry
setting.
I wrote a small tool to flush buffers (uses FlushFileBuffers),
and this works, but it would be much better to have a mode where
flushing is done automatically, even at the cost of performance
decrease.
(Obviously this mode exists, as the experience with the USB stick
shows...)
Regards,
Bernhard
Slobodan Brcin (eMVP)
Few facts from DDK:
1. RemovalPolicyExpectSurpriseRemoval = 3
2.
#define CLASSP_REG_HACK_VALUE_NAME (L"HackMask")
#define CLASSP_REG_WRITE_CACHE_VALUE_NAME (L"WriteCacheEnableOverride")
#define CLASSP_REG_REMOVAL_POLICY_VALUE_NAME (L"UserRemovalPolicy")
3. There is WriteCacheEnableOverride but this is override that is used to enable and not to disable caching in filesystems.
4. UserRemovalPolicy of 3 with override and set flag DeviceHotplug to true.
5. This is from DDK classpnp implementation. Comment in code speak for itself:
//
// this refers to devices which, for reasons not yet understood,
// do not fail PREVENT_MEDIA_REMOVAL requests even though they
// have no way to lock the media into the drive. this allows
// the filesystems to turn off delayed-write caching for these
// devices as well.
//
if (TEST_FLAG(FdoExtension->PrivateFdoData->HackFlags,
FDO_HACK_CANNOT_LOCK_MEDIA)) {
fdoData->HotplugInfo.MediaHotplug = TRUE;
} else {
fdoData->HotplugInfo.MediaHotplug = FALSE;
}
6. #define FDO_HACK_CANNOT_LOCK_MEDIA (0x00000001)
To conclude this try playing with registry value "HackMask" bit 0. Let us know if this helped.
Regards,
Slobodan
<bde...@init-ka.de> wrote in message news:1104166970.2...@f14g2000cwb.googlegroups.com...
Bernhard
- Setting HackMask=1 (in "...\Device Parameters\Classpnp" key)
did not help.
- Setting SpecialFlags=8 (in "...\Device Parameters\disk" key)
had the effect that I could not enable write caching in the
properties dialog any more (which would be OK), but did not
help either.
(This idea stems from the following DDK source line:)
#define HackDisableWriteCache (0x08)
- I then played around with IOCTL_STORAGE_SET_HOTPLUG_INFO:
I was able to persistently change the DeviceHotplug value to 1
for the CF device, but this did not help, too.
The MediaRemovable value is still 0 (it is 1 for the USB
stick), and I it seems I just can't let Windows treat the CF
card like a removable hotplug device :-(
Thanks for your help anyway
KM
See if this of any help:
http://groups-beta.google.com/group/microsoft.public.development.device.drivers/browse_frm/thread/1c384aad34673b20#b0feae113d014446
KM
Slobodan Brcin (eMVP)
UserWriteCacheSetting:
http://groups-beta.google.com/groups?q=UserWriteCacheSetting&qt_s=Search+Groups
I have no idea where you dig out "SpecialFlags" key but look at the following that only mention value that you use, this is
hardcoded hack for specific disk models.
Following call set entries that you mention:
ClassScanForSpecial(fdoExtension, DiskBadControllers, DiskSetSpecialHacks);
And as you can see DiskBadControllers is hardcoded.
CLASSPNP_SCAN_FOR_SPECIAL_INFO DiskBadControllers[] = {
{ "COMPAQ" , "PD-1" , NULL, 0x02 },
{ "CONNER" , "CP3500" , NULL, 0x02 },
{ "FUJITSU" , "M2652S-512" , NULL, 0x01 },
{ "HP ", "C1113F " , NULL, 0x20 },
// iomegas require START_UNIT commands so be sure to match all of them.
{ "iomega" , "jaz" , NULL, 0x30 },
{ "iomega" , NULL , NULL, 0x20 },
{ "IOMEGA" , "ZIP" , NULL, 0x27 },
{ "IOMEGA" , NULL , NULL, 0x20 },
{ "MAXTOR" , "MXT-540SL" , "I1.2", 0x01 },
{ "MICROP" , "1936-21MW1002002" , NULL, 0x03 },
{ "OLIVETTI", "CP3500" , NULL, 0x02 },
{ "SEAGATE" , "ST41601N" , "0102", 0x02 },
{ "SEAGATE" , "ST3655N" , NULL, 0x08 },
{ "SEAGATE" , "ST3390N" , NULL, 0x08 },
{ "SEAGATE" , "ST12550N" , NULL, 0x08 },
{ "SEAGATE" , "ST32430N" , NULL, 0x08 },
{ "SEAGATE" , "ST31230N" , NULL, 0x08 },
{ "SEAGATE" , "ST15230N" , NULL, 0x08 },
{ "SyQuest" , "SQ5110" , "CHC", 0x03 },
{ "TOSHIBA" , "MK538FB" , "60", 0x01 },
{ NULL , NULL , NULL, 0x0 }
};
Regards,
Slobodan
// HackDisableWriteCache
// CLASS_SPECIAL_DISABLE_WRITE_CACHE
"Bernhard" <bde...@init-ka.de> wrote in message news:1104181706.8...@z14g2000cwz.googlegroups.com...
Bernhard
I think I did similar things as was reported in
that posting (using IOCTL_STORAGE_SET_HOTPLUG_INFO to set
the DeviceHotplug flag), but it did not help.
A major difference is that my device is not removable
while the device in that posting is removable.
It would be not surprising (and in fact, coherent)
if the Hotplug info is completely ignored for
non-removable devices.
Regards,
Bernhard
Bernhard
the registry value UserWriteCacheSetting=0x0 is automatically
created when I un-check the "Enable write caching on the disk"
check-box in the properties GUI.
That was of course what I tried first, but it had no effect on
the corrupted file problems after power down.
I don't know much about caching issues, but I conclude from the
explanation for the "Optimize for quick removal" switch in the GUI
("This setting disables write caching on the disk and in Windows, ...")
that there are two levels of write caching: hardware level and Windows
level. The UserWriteCacheSetting value seems to have effect only on
hardware level caching. (But this is actually only speculation...)
At the moment I think I have to fall back on a tool that calls
FlushFileBuffers every 5 seconds or so - not very satisfactory,
but I hope this will reduce the errors considerably.
Slobodan Brcin (eMVP)
First do you use NTFS or FAT?
I think that NTFS was not created to work on removable disks so it might not flush data on its own. FAT actually flushed data on
removable disks.
Now when you mention this, I remembered that there was a discussion on this subject although I can't find the right thread :-(
Anyhow you can't do anything to disk internal caching trough MS registry switches, but rather trough sending proprietary SCSI codes
to disk device to disable caching or to alter internal caching behavior.
If you get corruption when you press reset button then this is windows software issue.
If you get corruption when you cut power then this might be internal disk caching problem.
Optimize for quick removal will try to pass all write request to disk controller as they come, with minimum or no delay. Also it
should have different behavior with regards on dirty bit.
http://groups-beta.google.com/group/comp.os.ms-windows.programmer.win32/browse_frm/thread/0a00a67f882086c7#4ee475b3e0c63a48
http://groups-beta.google.com/group/microsoft.public.win32.programmer.kernel/browse_frm/thread/a692df61fb93fb8d#4a434eecc6c89102
Regards,
Slobodan
"Bernhard" <bde...@init-ka.de> wrote in message news:1104230285.3...@z14g2000cwz.googlegroups.com...
Bernhard
I did all previous tests with NTFS with compression.
Now I prepared a CF disk with FAT and tested again
(The test is: recursively copy a directory tree
from network drive to disk, then (optionally) do
FlushFileBuffers, then cut power off, reboot, compare
files on disk to files on network. Autochk is enabled.)
With FAT things are even worse:
Without FlushFileBuffers, chkdsk complains about lost
clusters and creates some *.chk files, but the original
files are completely missing.
With FlushFileBuffers, everything is OK.
With NTFS, and without FlushFileBuffers, the situation
is as follows:
chkdsk detects no errors, all files look OK at first glance,
(file length, modification time etc. are OK),
but usually one file (not always the same!) consists of
binary zeros from some offset on. That means that the
NTFS "metadata" is OK, but the user data (file contents)
is corrupted...
So it seems that our only rescue is FlushFileBuffers!
The problem is not with our own application which we
can modify easily, it's with 3rd party SW (e.g. FTP
server, ZIP file extractor, ...) where it would be best
if flushing occurs at least if a file is closed.
KM
Here is an idea for you that you might have already tried but still worth to mention...
With W2K SP3 MS introduced the "Power Protected" Write Cache Option in additon to the "Write Caching" option.
Basically, to have the FS driver to issue Flush/Write-Through commands you will need to set "Write Caching" option to Enabled and
the "Power Protected" option to Disabled (see more info here: http://support.microsoft.com/?kbid=332023).
Instead of messing up with API for the moment you can try the easiest way - use RK utility diskcache (some info here
http://support.microsoft.com/kb/811392/EN-US)
If it helps, let us know.
--
Regards,
KM, BSquare Corp.
Bernhard
I did not yet get the dskcache tool but I will check this, too.
Thank you for the link, it contains the best information that I have
read about this issue so far. And it seems that the FlushFileBuffers
API is indeed the only way to insure proper cache flushing...
And I am somewhat relieved when I read the following:
"Writing to the registry is an example of an operation that results
in the FlushFileBuffers API being called and the SYNCHRONIZE CACHE
command being sent to the disk."
So at least internally in Windows, they seem to know how to do it...
Regards,
Bernhard
Slobodan Brcin (eMVP)
Since we are dealing with embedded here if all other suggestion fail, you have one more option on your disposal.
In DDK you have working disk driver example. So you can modify it to flush all request when you want them (always).
Regards,
Slobodan
"Bernhard" <bde...@init-ka.de> wrote in message news:1104322585.2...@f14g2000cwb.googlegroups.com...