Comment by supermatt

4 years ago

So its basically implementation specific, and macOS has its own way of handling it.

That doesnt make it worse - in fact it permits the flexibility you are now struggling with.

edit: downvotes for truth? nice. go read the posix spec then come back and remove your downvotes...

Probably more like downvoted because missing the point.

Sure fsync allows that behavior, but also it's so widely misunderstood that a lot of programs which should do a "full" flush only do a fsync, including Benchmarks. In which case they are not comparable and doing so is cheating.

But that's not the point!

The point is that with the M1 Macs SSDs the performance with fully flushing to disk is abysmal bad.

And as such any application with cares for data integrity and does a full flush can expect noticable performance degradation.

The fact that Apple neither forces frequent full syncs or at least full syncs when a Application is closed doesn't make it better.

Though it is also not surprising as it's not the first time Apple set things up under the assumption their hardware is unfailable.

And maybe for a desktop focused high end designs where most devices sold are battery powered that is a reasonable design choice.

  • "And maybe for a desktop focused high end designs where most devices sold are battery powered that is a reasonable design choice"

    Does the battery last forever? Do they never shut down from overheating, shut down from being too cold, freeze up, they are water and coffee proof?

    Talk to anyone that repairs mac about how high-end and reliable their designs trully are - they are better than bottomn of the barrel craptops, sure, but not particularly amazing and have some astounding design flaws.

    • As the article points out, a lot of those cases can be detected with advanced notice (dying battery, and overheating - probably even being too cold). In those cases the OS makes sure all the caches are flushed.

      Spilled drinks are a viable cause for concern, but if they do enough damage to cause an unexpected shutdown, you've probably got bigger issues than unflushed cache.

      2 replies →

  • I mean the Apple hardware in question is usually a laptop, which has its own very well instrumented battery backup. In most cases the hardware knows well in advance if the battery is gonna run dry.

    And yes the hardware is failable. But the kind if failure that would cause the device to completely lose power is extremely rare. The OS has many chances to take the hint and flush the cache before powering down.

    Note: this is pure conjecture.

  • > The point is that with the M1 Macs SSDs the performance with fully flushing to disk is abysmal bad.

    How sure are we the drives that flush caches more quickly are actually flushing the caches?

    • Good Point.

      A simple test can be to see the degree of dataloss you can occur with a hard power off.

      I think the author did that test for M1 Mac but idk. if they did the test with the other laptops.

      But then the M1 Mac is slower when flushing then most SSDs out there and even some HDDs. I think if most SSDs wouldn't flush data at all we would know of that and I should have run into problems with the few docent hard resets I ran into in the last few years. (And sure there are probably some SSDs which cheap out on cache flushing in a dangerous way, but most shouldn't as far as I can tell).

      1 reply →

What is worse is their NVMe controller having 50x worse flush performance than the competition.

  • The competitions controller may be ignoring the F_FULLFSYNC. This is a known issue which is why apple have approved vendors for mac pro drives.

    • It isn't, because otherwise it would be showing the ~same performance with and without sync commands, as I showed in the thread. There is a significant performance loss for every drive, but Apple's is way worse.

      There is no real excuse for a single sector write to take ~20ms to flush to NAND, all the while the NAND controller is generating some 10MB/s of DRAM traffic. This is a dumb firmware design issue.

      9 replies →