VOGONS


First post, by bakemono

User metadata
Rank Oldbie
Rank
Oldbie

OK, so here is a weird one... My computer has two HDDs, one with NTFS and the other with 2x FAT32 partitions. I have a program that does a lot of small writes throughout a file. But the files aren't very big, so usually execution is nearly instantaneous. Running it on a network drive might take 1 second or so. Running it on the NTFS drive is always instantaneous. But on the FAT32 drive (either partition), it is instantaneous some days, while others it will take several seconds. When it is in 'slow mode', it seems very much like Windows is sending a write command to the HDD for every filesystem write operation that happens instead of gathering several writes to the same sector or allocation unit.

Whatever the condition is, it is determined at boot time and doesn't change afterward. In other words, if I boot up and discover that the program runs slow on FAT32 today, I can be certain that it will stay that way until I reboot, at which point it might go back to normal or it might go into 'slow mode' again.

Reads aren't affected at all. HDtach shows the same benchmark result either way. HDD SMART data is fine.

I first noticed this phenomenon about three years ago, but it was very rare. Recently I upgraded the motherboard, and now it happens much more frequently.

Anybody ever heard of this before? I don't really know what else to do except add this to my list of "things to trace with remote kernel debugging someday"

GBAJAM 2024 submission on itch: https://90soft90.itch.io/wreckage

Reply 1 of 8, by TrashPanda

User metadata
Rank l33t
Rank
l33t

Common denominator here is the drive itself, I would look into that first, its possible that version of the drive had firmware issues in certain hardware configurations. Depending on the age of the drive there might be fixes available from the manufacturer or known workarounds other users have come up with.

Reply 2 of 8, by bakemono

User metadata
Rank Oldbie
Rank
Oldbie

Good suggestion but I put the serial number into Seagate's Download Finder and it says there are no firmware updates for it.

GBAJAM 2024 submission on itch: https://90soft90.itch.io/wreckage

Reply 3 of 8, by TrashPanda

User metadata
Rank l33t
Rank
l33t
bakemono wrote on 2022-11-14, 11:00:

Good suggestion but I put the serial number into Seagate's Download Finder and it says there are no firmware updates for it.

Check around on forums, see if anyone else is having similar issues to yours.

Reply 4 of 8, by jmarsh

User metadata
Rank Oldbie
Rank
Oldbie

This was a known issue with win2k (KB290757: "write caching settings for hard disk will not persist after you restart your computer"). The "fix" was to install service pack 3.

Reply 5 of 8, by bakemono

User metadata
Rank Oldbie
Rank
Oldbie

I already have service pack 3 installed (and 4 and beyond) but it's good to know that it may be a setting on the HDD itself. There is an ATA command EFh Set Features which can enable/disable the drives's write cache. If that turns out to be the issue then I can probably make my own fix.

GBAJAM 2024 submission on itch: https://90soft90.itch.io/wreckage

Reply 6 of 8, by jmarsh

User metadata
Rank Oldbie
Rank
Oldbie

Well no, the main write-caching should be done by the OS (using unallocated system memory) and that's what "write-caching policy" refers to when you view the properties of a drive in device manager. win2k had a known issue where it would randomly turn it off after a reboot which sounds like it matches your description exactly.
The actual write buffer built-in to the drive (if any) would be much smaller and still incurs an overhead of sending the data for each individual write over the bus to the drive, performance is a lot better if that can be avoided/coalesced.

Reply 7 of 8, by bakemono

User metadata
Rank Oldbie
Rank
Oldbie

I think it is solved now.

Short answer:
I had to find the proper registry key for the drive under HKLM\SYSTEM\CurrentControlSet\Enum\IDE
Then under Device Parameters I added a 'Disk' key and a dword value called UserWriteCacheSetting set to 1

jmarsh wrote on 2022-11-15, 11:31:

Well no, the main write-caching should be done by the OS (using unallocated system memory) and that's what "write-caching policy" refers to when you view the properties of a drive in device manager.

Long answer:
I believe that normally it wouldn't be necessary to add a registry key, because going to the properties page that you refer to and enabling write caching there would be enough. The problem is that the properties page didn't exist on my computer. The tab just wasn't there. So I tried to find out why it was like that.

STORPROP.DLL is responsible for the properties/settings tabs for HDDs, optical drives, and IDE channels. I did some API snooping I noticed that BlackWingCat's extended kernel includes a SETUPXPI.DLL which seems to be some XP version of SETUPAPI.DLL. DEVMGR.DLL is patched to reference SETUPXPI instead of SETUPAPI but STORPROP.DLL isn't included in extended kernel so it is still the old version from SP4. DEVMGR would call SETUPXPI which would call STORPROP DiskPropPageProvider but the call seemed to fail.

I patched STORPROP.DLL to reference SETUPXPI instead of SETUPAPI and now the missing properties tab is back! As an added bonus, the 'Advanced Settings' tab for each IDE channel which was present but broken is now working. Finally, my SATA DVD drive is no longer stuck in PIO mode...

GBAJAM 2024 submission on itch: https://90soft90.itch.io/wreckage

Reply 8 of 8, by Geri

User metadata
Rank Member
Rank
Member

consider switching to a real operating system, such as linux (debian) which has about a 30 years long technological ahead over windows, and you also have full control over disc caching.

TitaniumGL the OpenGL to D3D wrapper:
http://users.atw.hu/titaniumgl/index.html