SSD with write cache buffer flushing turned on is way slower in AS SSD but not CDM

Question

When running a benchmark using the program AS SSD on an NVMe drive, When the second checkbox seen in the image below is unchecked, the drive gets terrible write performance in AS SSD (see first benchmark screenshot below), but not in CrystalDiskMark (see last screenshot); however, if I check that box, then AS SSD performs well. Does anyone know what's going on here? My concern is that according to that checkbox description, I should NOT have it checked since my drive doesn't have its own power supply, but AS SSD is so slow, I'm concerned other programs may be affected.

In case it's helpful, I learned about that checkbox in the first place from reading https://www.reddit.com/r/Dell/comments/628odr/toshiba_nvme_slow_write_speed_fix/, but this doesn't explain to me why CDM would still be fast. See also Slow SSD performance (Toshiba 1GB NVMe). I updated my Intel RST drivers and that didn't help.

I understand there could be a roundabout driver solution here, but I want to stay within warranty and try to find out what's going on so I can get Dell to support this and issue an official solution.

Solution 1

Usually data losses may only be possible in cases of faulty hardware or unclean shutdowns (sudden power outages, heat protection kick-ins, BSODs, etc.). But many programs are aware of that (all programs which are designed with safety in mind) so, for example, they don't just overwrite data in place: they create a new file, write data there, flush cache to ensure it's written, then remove the old file.

Without this checkbox, if failure occurs at any point, you'll always have at least the old version of data.

When box is checked (without buffer flushing), in case of power failure or sudden reset, data losses may be vast and uncontrollable, you may even lose data unrelated to files being written because file-system updates occur with same principles. You may even completely lose all data on the volume, if failure occurs in an especially unfortunate time. Even worse: in some cases, you may lose data on clean shutdown/reboot, if drive doesn't flush cache on its own before reset.

Because of that, disabling buffer flushing without independent power supply for the drive is playing with fire. If you're using SSD for non-original data (caches, mirroring of slower storage for fast access, non-original program files, Steam or other means of games installs, etc), and willing to risk it (though in case of steam, beware of loosing savefiles, depending on where games put them), you may check that. But expect catastrophic failures occasionally (especially in case of unclean shutdown/unmount), and probably just reformat and re-fill the drive with data in such a case, instead of trying to recover.

Also, ensure performance gains are real and significant. Because maybe the first test just tries to flush after each write, which will indeed cripple performance, but barely this is done by any widely used application at all.

related:

1. blogs.msdn.microsoft.com/oldnewthing

   • comment evidence: Disabling cache flushing causes Data losses on reboot after installing windows updates
   • Dangerous setting is dangerous: This is why you shouldn’t turn off write cache buffer flushing
   • Flushing your performance down the drain, that is

2. Sandisk ExpressCache manual:

   • only disable flushing if your drive have external power supply (red text at bottom of page 12)

3. Some other forums

   • https://forum.bitsum.com/forum/index.php?topic=3383.0

Solution 2

It seems to me by Occam's Razor, if AS SSD has bad results when buffer flushing is on, then this reflects the fact that data takes longer to be written to the disk. The measuring by AS SSD seems to go deeper than CrystalDiskMark. CrystalDiskMark apparently does not care what happens after the write is issued to the OS, considering the data as already written, while AS SSD hooks into the OS.

Modern disks have a rather large RAM cache that is usually internally protected from power cuts, so there is no need to insist on waiting for the disk controller to fully write the data to its internal disk - this just harms performance.

See also this article : Flushing your performance down the drain, that is.

Comments

[g491]

Interesting theory about AS SSD calling flush but why would updating the driver boost performance for this as mentioned in the Reddit link I posted?

[Nauf_M]

Performance boost is explained in another link you posted - superuser.com/q/1107759/131936. Basically, it's bugs/bad optimization of controller driver, which have been fixed in newer version.

[Nauf_M]

For example, here is issue published by Intel: search for "1804279652" on page downloadmirror.intel.com/26730/eng/Release_Notes_15_5_PV.htm

[g491]

Regarding your comment of "Even worse: in some cases, you may loose data on clean shutdown/reboot, if drive doesn't flush cache on its own before reset." do you have any source for this? I can't imagine that Windows wouldn't issue a flush command before a clean reboot / shutdown if this were a potential issue. Thanks

[Nauf_M]

@g491 yes, it's first link in my reply (read the linked comment). Also, see post of Raymond Chen on the topic, he is Windows developer. He says, even though Windows flushes data from RAM, with this checkbox it does not send "flush" command to the drive, so the drive could flush it's own cache when it feels best. Even on shutdown. And some drive's firmware is too buggy and does not flush automatically on shutdown/before reset.

[Luke Usherwood]

For SSDs, write caching still harms data integrity along with performance. Note the article from 2010 talks of them spinning flywheel devices. ;-) SSDs are a whole different kettle of fish. I have an SSD with capacitor backup to complete flash-memory page writes. However on a hard power cut (and also a kernel crash) I regularly experience file corruption even at Window's "safer" level of write caching: after reboot, certain files are the correct size but the content is full of zeros where the data should be. No problems reported by scandisk.

[Luke Usherwood]

Hmm, actually what I can't say with confidence is whether the data loss would have occurred anyway with write caching disabled. I've only just started to try this after many years of SSD data loss, across windows 7 & 10 and multiple SSDs. Turns out write caching only made 10% difference in practice (worst case!) to compiling code - and actually I need-only disable it on one drive, as I can shift the bulk of my writes to a temp drive, and that way I don't even lose that 10% performance.