macOS 的存储“黑魔法”，用可靠性换取表面的高性能

[felixcode]

https://twitter.com/marcan42/status/1494213855387734019



简单来说，造成的后果是如果忽然断电或 Kernel Panic ，很可能会造成数据丢失，在笔记本电脑上可能不是大问题，但在 Mac Mini 或 Pro 上，很容易造成数据损坏。

[secondwtq]

原来事 Asahi Linux 的开发者

新的冷知识“I can get these stats because the NVMe controller is integrated into the SoC and 'drive cache' is just normal memory (it's unified just like GPU memory), and Apple have very good instrumentation of things like DRAM bandwidth utilization from different SoC agents.”

"If you run a durable database on an M1 today, try a cheap flash drive."这下金士顿了

[Mirage09]

奇怪 为什么会有那么大的 flush penalty

[atone]

似乎是因为 macOS 和 Linux 的具体实现机制不同。参见
https://mjtsai.com/blog/2022/02/17/apple-ssd-benchmarks-and-f_fullsync/

[wanguorui123]

感觉还能接受，重要文件不能靠单机存储

[minsheng]

@Mirage09 作者的分析是有固件 bug ，flush 指令的时候控制器有着异常高的内存读取流量。然后因为 iOS 平台一直没有人用 F_FULLSYNC ，就算有需求也是用 F_BARRIERFSYNC ，所以压根没有人注意到这个 bug 。最后 bug 从 A 系列跑到了 T2 最后跑到了 M1 里面，直到这次移植 Linux 才被人发现。

[0ZXYDDu796nVCFxq]

补充一些信息：
fsync() 是 POSIX 里定义的函数，这个函数必须等数据写入磁盘或者发生异常才能返回结果
macOS 修改了逻辑，fsync() 只是把数据写入到驱动器，并没有保证落盘，数据还在驱动器的缓存里
使用 F_FULLSYNC 后，macOS 的 nvme 磁盘性能会大幅下降

[xtinput]

还没遇到过数据丢失，所以不管它怎么实现的，苹果既然敢这么做肯定是有其它的机制来确保稳定可靠的，说不定是配合了硬盘的主控芯片策略来保证稳定可靠的吧

[xtinput]

固态硬盘的主控算法和芯片决定了它的质量

[felixcode]

@xtinput
没有其它机制，有人测试了，断电前 5 秒以上的数据都没了。

[0ZXYDDu796nVCFxq]

@xtinput 建议看完 Hector 的长 tweet ，你的表述都不正确

[StevenRCE0]

和 APFS 卧龙凤雏了属于是。

[xtinput]

@felixcode 哦，没关系，笔记本基本没突然断电的可能，我只用笔记本