这是一个创建于 1039 天前的主题，其中的信息可能已经有所发展或是发生改变。
https://twitter.com/marcan42/status/1494213855387734019
简单来说，造成的后果是如果忽然断电或 Kernel Panic ，很可能会造成数据丢失，在笔记本电脑上可能不是大问题，但在 Mac Mini 或 Pro 上，很容易造成数据损坏。
简单来说，造成的后果是如果忽然断电或 Kernel Panic ，很可能会造成数据丢失，在笔记本电脑上可能不是大问题，但在 Mac Mini 或 Pro 上，很容易造成数据损坏。
第 1 条附言 · 2022-02-18 10:18:17 +08:00
https://news.ycombinator.com/item?id=30370551
HackerNews 上的讨论
HackerNews 上的讨论
第 2 条附言 · 2022-02-19 02:54:05 +08:00
 |
1
secondwtq 2022-02-18 04:43:42 +08:00
原来事 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."这下金士顿了 |
 |
2
Mirage09 2022-02-18 06:05:39 +08:00
奇怪 为什么会有那么大的 flush penalty
|
 |
3
atone 2022-02-18 09:24:40 +08:00  1
似乎是因为 macOS 和 Linux 的具体实现机制不同。参见
https://mjtsai.com/blog/2022/02/17/apple-ssd-benchmarks-and-f_fullsync/ |
 |
4
wanguorui123 2022-02-18 09:32:04 +08:00
感觉还能接受，重要文件不能靠单机存储
|
 |
5
minsheng 2022-02-18 10:57:27 +08:00
@Mirage09 作者的分析是有固件 bug ，flush 指令的时候控制器有着异常高的内存读取流量。然后因为 iOS 平台一直没有人用 F_FULLSYNC ，就算有需求也是用 F_BARRIERFSYNC ，所以压根没有人注意到这个 bug 。最后 bug 从 A 系列跑到了 T2 最后跑到了 M1 里面，直到这次移植 Linux 才被人发现。
|
 |
6
0ZXYDDu796nVCFxq 2022-02-18 16:22:01 +08:00 1
补充一些信息：
fsync() 是 POSIX 里定义的函数，这个函数必须等数据写入磁盘或者发生异常才能返回结果 macOS 修改了逻辑，fsync() 只是把数据写入到驱动器，并没有保证落盘，数据还在驱动器的缓存里 使用 F_FULLSYNC 后，macOS 的 nvme 磁盘性能会大幅下降 |
 |
7
xtinput 2022-02-18 21:09:24 +08:00
还没遇到过数据丢失，所以不管它怎么实现的，苹果既然敢这么做肯定是有其它的机制来确保稳定可靠的，说不定是配合了硬盘的主控芯片策略来保证稳定可靠的吧
|
|
8
xtinput 2022-02-18 21:10:05 +08:00
固态硬盘的主控算法和芯片决定了它的质量
|
|
10
0ZXYDDu796nVCFxq 2022-02-19 10:44:32 +08:00 via Android
@xtinput 建议看完 Hector 的长 tweet ，你的表述都不正确
|
 |
11
StevenRCE0 2022-02-19 12:26:37 +08:00
和 APFS 卧龙凤雏了属于是。
|
Select Language