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.

Answer 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

Answer 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.