cas

Get your dangerous XP Cache Filter here

Recommended Posts

 XP Cache Filter



This program installs a small filter driver, which clears the FUA (Force

Unit Access) bit from SCSI write commands.  This has the potential to

improve write performance, at the expense of greater risk in the case of

disk or power failure.



This is free software, and is offered without any warranty expressed or

implied.  As a kernel mode driver, XP Cache Filter has the potential to

corrupt data and reduce system stability.



INSTALLING THIS DRIVER COULD RESULT IN 100% DATA LOSS.



Proceed at your own risk.



cas

As described in this thread, Windows XP flushes meta data to disk synchronously to reduce the likelihood of data loss in the case of a disk or power failure. This is a good idea.

Since other operating systems like Linux and Windows 2000 do not do this however, you may see lower SCSI performance on Windows XP than you did on these other systems. In the rare case that you actually have an application that requests writes directly to the disk media, you will see dramatically worse performance.

For those who like to live dangerously, or at least figure they were just fine before, I present XPCacheFilter.

Recognize that this is a brand new kernel mode driver, which has never been used outside of my lab. Exercise great care in using this software.

Please post your results here, to keep the XP SCSI threads uncluttered from issues relating specifically to XPCacheFilter.

Share this post


Link to post
Share on other sites
How easy is it to uninstall? :)

If you run the executable on the command line (without switches), it will display instructions on how to install and uninstall the driver.

If you want some third party confirmation that it has actually been uninstalled, open the Device Manager. Click View->Show hidden devices. Look under Non-Plug and Play Drivers.

One of XP's nice features, is that it is pretty easy to boot to the Last Known Good config, if you happen to load a bad device driver.

Share this post


Link to post
Share on other sites
Guest russofris

I have a 2940UW and a barracuda 4GB lying around. I will scrounge together a PC and test.

Thank you for your time,

Frank Russo

Share this post


Link to post
Share on other sites
Windows XP flushes meta data to disk synchronously to reduce the likelihood of data loss in the case of a disk or power failure.  This is a good idea.

Since other operating systems like Linux and Windows 2000 do not do this however, you may see lower SCSI performance on Windows XP than you did on these other systems.

I don't know of any Linux distribution that enables this by default, but it's just another mount option if synchronous metadata writes are what you want. You can also enable synchronous data writes for still greater data integrity, and even worse performance, though admittedly I have no idea if Windows does this or not.

As for the reason that Linux distributions do not enable this by default, see below, where Linus Torvalds replies to a message in which it was suggested that disabling the [again, optional] synchronous metadata I/O was Bad Thing™.

Linus[/url]"]

Synchronous meta-data updates are STUPID:

(a) it's bad for performance

(B) it's bad for filesystem stability

(a) is obvious, and even BSD people will agree to that.  But (B) is not as obvious, and BSD people mostly say "Huh?"

In short, updating meta-data synchronously almost guarantees that the filesystem structure will be up-to-date after a crash, but it will _not_ guarantee that the actual file data will be up-to-date.  In fact, it will often result in a filesystem that "fsck" thinks is perfectly ok, _despite_ the fact that you have corruption.

Now, the entire message seems to be talking about how Linus thinks it is a bad idea to use sync metadata I/O unless you are also using sync data I/O, which Linus further supports in later messages on USEnet. Apparently, BSD was using this to quell complaints from fsck (File System Check, the Unix equivalent of Scandisk, for those who haven't used Unix), but it's the whole idea of synchronous metadata I/O without synchronous data I/O that he seems to be attacking.

Read the entire thing (by clicking on "Linus") in case I took it too far out of context.

As I said, I have no idea if Windows uses synchronous data I/O or if they have some sort of solution to the problem described above.

Share this post


Link to post
Share on other sites

This is great! I have a buddy with four 75GB 75gxp's running RAID0 on a HPT 404 on an abit KT7 with a Duron 850 o/c to 1200. He uses a sparkle 250W PS and doesn't believe in 4in1's! He has no UPS either. Sounds like this is the perfect enhancer for him! :)

Cheers!

Share this post


Link to post
Share on other sites

It occured to me that a few readers may not be familiar with some of the terminilogy used in this thread.

metadata is "data about data". In general, metadata is information about your data, such as filenames, the location(s) of a file on your hard disk, security attributes about your file, etc.

data is the same term you're already familiar with. It's the actual contents of a file, rather than the information about the contents of a file.

Having just the data recorded isn't enough. If no metadata exists, or if it is corrupt, the system might be confused about where it can find a file, if there are any files, etc. Generally, if metadata corruption occurs, you lose files (or your entire filesystem, including all files!) even though the actual data may be perfectly intact.

Using synchronous metadata I/O: Rather than waiting on metadata writes, metadata is written immediately. Once a file write occurs, the system writes the metadata as soon as the system can possibly do it. I'm not sure if asynch metadata I/O implies that the metadata is written before or after the data write, or if that's simply up to the filesystem designer. The alternative is to wait a short time. This can be for several reasons, for example, if there are 20 write operations which need to be done, they can be written in an order that requires the least movement of the disk. Also, if the disk is busy doing something else, the system can hold off on making writes until it is finished, which prevents the disk from being interrupted and possible prevents needing to move the heads clear across the platter in the middle of a very time-sensitive read or write.

If any of this is incorrent, please let me know, preferably without biting my head off :)

Share this post


Link to post
Share on other sites
Guest russofris
This is great!  I have a buddy with four 75GB 75gxp's running RAID0 on a HPT 404 on an abit KT7 with a Duron 850 o/c to 1200. He uses a sparkle 250W PS and doesn't believe in 4in1's! He has no UPS either.  Sounds like this is the perfect enhancer for him! :)

Cheers!

Hey cas, you may wish to jot down a quick FAQ. That might prevent posts like this. Basically, who should (not!!!) use this patch.

Thank you for your time,

Frank Russo

Share this post


Link to post
Share on other sites
Guest Eugene
This is great!  I have a buddy with four 75GB 75gxp's running RAID0 on a HPT 404 on an abit KT7 with a Duron 850 o/c to 1200. He uses a sparkle 250W PS and doesn't believe in 4in1's! He has no UPS either.  Sounds like this is the perfect enhancer for him! :)

Cheers!

Hey cas, you may wish to jot down a quick FAQ. That might prevent posts like this. Basically, who should (not!!!) use this patch.

Thank you for your time,

Frank Russo

I was scratching my head over that one too ;)

Share this post


Link to post
Share on other sites

Frank, I think he was joking. Um, I hope so, anyway.

Share this post


Link to post
Share on other sites
Frank, I think he was joking.  Um, I hope so, anyway.

I think so too.. at least that's how I interpreted it because of the 'no UPS' part.

Share this post


Link to post
Share on other sites

No guys the sad part is I really DONT think he was joking about fixng the ide raid.

The good news is the patch works. Unfricking real ! We finally have a fix after all this time.

Job well done !

Tex

Share this post


Link to post
Share on other sites

Sivar, you are confused. Remember, we are talking about completing individual writes to the platter, in the presence of a writeback cache.

Here is something to get you started:

As it stands, the Linux SCSI subsystem has no mechanism to force a disk cache write through. The SCSI WRITE(10) command has a Force Unit Access bit (FUA) to do exactly that, but we don't use it.

The above was written almost six years after your Linus quote.

Share this post


Link to post
Share on other sites
The good news is the patch works.  Unfricking real !

Really?

That's great news. I don't own a single SCSI disk, so you are my first confirmation. (and thanks for the compliment)

Share this post


Link to post
Share on other sites
The good news is the patch works.  Unfricking real !

Really?

That's great news. I don't own a single SCSI disk, so you are my first confirmation. (and thanks for the compliment)

The writes are within a thousand or so of what they were dynamic. This is a lsi u160 controller and a hitachi scsi drive. The writes now hit about 63,000 on atto with a basic disk and ntfs.

It seems the way the bios/drivers combo's are handling this problem varies. With this for me both the writes and reads were always equally screwed on atto. Is there by any chance also a flag for the reads that could be being handled improperly by mine? My reads match what they were before the patch. But before they were equal to the horrible writes so I have to wonder if there is a possibly a flag that could be modded to make my bad reads match the now fixed writes. I know my problem is differant and most have not had a read problem also but I do. And since your filter fixed the writes I suspect you might also be able to have one for me to patch the reads? (grin) Uhhh... Have I told ya lately what a gebius you are and how I think I love you? (lmao)

Thanks Again !

Tex

Tex

Share this post


Link to post
Share on other sites
Uhhh... Have I told ya lately what a gebius you are

Tex

Great .. I'm trying to butter the guy up for a favor and tell him he is a GENIUS and I spell it of course "gebius"... (long sigh........) been that kinda day I'm afraid.

Tex

Share this post


Link to post
Share on other sites

sar·casm ( P ) Pronunciation Key (särkzm)

n.

A cutting, often ironic remark intended to wound.

A form of wit that is marked by the use of sarcastic language and is intended to make its victim the butt of contempt or ridicule.

[Late Latin sarcasmus, from Greek sarkasmos, from sarkazein, to bite the lips in rage, from sarx, sark-, flesh.]

Source: The American Heritage® Dictionary of the English Language, Fourth Edition

The box in question was set up with the most (un)trusted hard disks in the world, then striped x4. Combine that with overclocking, VIA KT133, underpowered power supply and you have a recipe for disaster. At least that's what he thought!!! The box has been running this way since April 2001 and (outside of the usual operator mistakes) is still running strong! It always works that way too! When you WANT something (as expected) to fail, it doesn't. When you depend on something, it fails. Mr. Murphy in your house.

Cheers!

Share this post


Link to post
Share on other sites
sar·casm    ( P )  Pronunciation Key  (särkzm)

n.

A cutting, often ironic remark intended to wound.

A form of wit that is marked by the use of sarcastic language and is intended to make its victim the butt of contempt or ridicule.

[Late Latin sarcasmus, from Greek sarkasmos, from sarkazein, to bite the lips in rage, from sarx, sark-, flesh.]

Source: The American Heritage® Dictionary of the English Language, Fourth Edition

The box in question was set up with the most (un)trusted hard disks in the world, then striped x4.  Combine that with overclocking, VIA KT133, underpowered power supply and you have a recipe for disaster.  At least that's what he thought!!!  The box has been running this way since April 2001 and (outside of the usual operator mistakes) is still running strong!  It always works that way too!  When you WANT something (as expected) to fail, it doesn't.  When you depend on something, it fails.  Mr. Murphy in your house.

Cheers!

Sparkles a decent brand... I don't think it's underpowered for a Athlon model 3 (1st Duron's)... the kt133 was no worse than the kx133.. and I had my kx133 machine up for weeks at a time before...

btw, I had and continue to have 2x 75gxp's in raid0 for over 2 years.... ;-) but I used a better controller... (fastrack66)

Share this post


Link to post
Share on other sites

Cas, et al,

I have to ask - what do YOU believe the value is of synchronous metadata writes when using a journaled filesystem, i.e., NTFS or ext3? Can anyone think of why this would be important - is there something in the metadata that is not transparent from the journals? Or is the whole point of synchronous updates to merely assist non-journaled systems, i.e., FAT-based?

If that's the case then MS really messed up by not making that synchronous metadata writes dependent upon the type of file system being written...

Future Shock

Share this post


Link to post
Share on other sites

When mounted on storage systems with a write back cache, journaling and careful write filesystems do not perform as advertised. By using the FUA bit to selectively disable the wb cache for specific writes, integrity can be maintained, while retaining some of the performance benefits of the cache. This is why OS designers recommend that ATA disks have their writeback caches disabled.

As I mentioned here however, users are of a different mind, and will often choose performance over integrity.

While some users lament at the loss of performance, this is really the way it should have been all along. If anything, the filesystems themselves should offer a looser coherency model as an option (which could bring other optimizations as well). In the absence of such controls, we will have to make do with this crude substitute.

Share this post


Link to post
Share on other sites

time for benchmarks that prove absolutely nothing! (except maybe one)

my system:

Athlon XP1800+

MSI Turbo2 KT133A

512MB PC133 RAM

WinXP (non-sp1)

5400 RPM IDE 20 (didn't use this at all)

LSI U160 single channel

X-15 36LP 18gig

almost every patch you can think of, to name a few; via latency, 4in1's (not hyperion), lsi aspi driver, raid performance patch, etc etc etc...

now for stopwatch tests! yay!

BEFORE DANGEROUS XP FILTER

BF1942 startup - 18.9 seconds

BF1942 single player load map - 21.7

booting XP - 39.8

581MB tar file copy (from C: to C:) - 90 seconds

the untaring of the file - 56.0

raring to the final 603MB .bin file - 74

now some bechmarks! one of only any significance:

before.jpg

*^ see note at bottom of post ^*

hdbefore.jpg

AFTER DANGEROUS XP FILTER!!!!:

BF1942 startup - 22.6

BF1942 single player load map - 22

booting XP - 44 seconds (then another reboot, 40 seconds)

581MB tar file copy (from C: to C:) - 83 seconds

the untaring of the file - 55.0

raring to the final 603MB .bin file - 78

after.jpg

hdafter.jpg

since i only have 1 cheetah, i can't do a file copy from a data source that can write at more than 50MB/s

so what's the meaning of this post? well... just to show that there's no real performance increase (at least, for my system) and i even got an error after installing the patch when i closed explorer (it was a management program that crashed or something)

so i'll be uninstalling it and keeping my data safe (i didnt even backup any data before doing this, hehe)

*^note^* actually, when reviewing some of my older ATTO's, the "before" results are kindof low. as i had done some tweaking with patches and have come up with the 45MB writes/51MB reads like the "after" result

i'm not saying cas didn't do anything, because i'm sure he did :)

but i'm hoping i can help prevent any sort of freakout from some uninformed users thinking this patch is the GOLDEN KEY to "fix" everything

Share this post


Link to post
Share on other sites
...so what's the meaning of this post? well... just to show that there's no real performance increase (at least, for my system)...

Yes indeed, not for your system. Note that You had 40MB/s+ writes before the patch in question. Some are struggling at 20MB/s, and they CAN see the difference with this patch. Note that You also have the "notorius" VIA133a chipset that has some PCI bandwidth limitations without correct patches.

Cheers,

Jan

Share this post


Link to post
Share on other sites
Guest russofris
sar·casm    ( P )  Pronunciation Key  (särkzm)

Don't make me come over there!!!!!!

Ok, I feel better now that I know that you were kidding.

Frank

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now