Originally posted by: psychochip
Originally posted by: PCPETE
What about for other brand drives?!
NOTE: The MaxBoost driver is not intended for use with non-Maxtor/Quantum drives or system configurations other than specified above. Attempting to run the MaxBoost driver on unsupported system configurations can lead to decreased system performance or inconsistent system or disk drive behavior. Also, in the event of a sudden system shutdown, data stored in your system cache and not on the drive may be lost and recovery of that data may not be possible.
Honestly, based on my prior experiences with the Promise Ultra66/Ultra100 cards, and their original 1.60 series Ultra Family Drivers (and their respective EVIAN.SYS/PTICACHE.VXD drivers for NT/Win9x), I _WOULD NOT_ install these.
Somehow, I think that these might be the Return of the Evil Promise Caching Drivers, or something. Maybe they're not, maybe Maxtor wrote them themselves, but non-MS storage-stack drivers make me very nervous.
Some of the effects that I saw, were:
1) *Reduced* system performance, under certain load conditions. Especially in low-memory situations. It seems that (at least under W2K SP2 with the Ultra66 and driver version 1.60 build 36's cache driver), that the system was much less responsive under VM thrashing conditions. I hypothesize that MS's own internal system-cache code doesn't have as much internal lock-contention (those that read LKML would understand this) as Promise's cache drivers, which would have to route several different I/O codepaths all to their single driver, probably with a single mutex or lock somewhere in their code, almost like the infamous "Win16 Mutex" in Win9x.
2) Incompatibility with "Hibernate" functionality (under W2K SP2 at least). As it turns out, because the Promise cache driver allocates system memory for storing disk-cache information, and is not considered by the OS to be a "system" disk-cache buffer instead, the contents of the Promise cache are preserved across Hibernate sessions. This is _BAD_. If you multi-boot a system, and then modify the filesystem, the "stale" filesystem cache information is STILL PRESENT in the Promise cache driver's memory blocks when resuming from Hibernate. This can lead to SEVERE filesystem corruption if you them write to the physical disk, and write out any of that stale disk-cache data. (I originally thought that this was a defect in W2K itself, and then I realized the interaction with the Promise cache drivers.)
Now, all of the above may or may not have anything to do with the new Maxtor disk-cache drivers. Hopefully not. However, I know that Maxtor uses OEM Promise controllers, and the newest available Promise Ultra Family driver, is ONLY publically available on Maxtor's site. It's not even on Promise's site. So perhaps, Maxtor and Promise might be sharing some software R&D expenses somewhere. It wouldn't surprise me to see that. Promise's own software R&D and support absolutely sucks.
If anyone has actually tried this, can you test (on a non-critical/test system), the whole hibernate/multi-boot scenario for me? I'm really curious if the Maxtor disk-cache drivers have the same defect.