Regarding this topic in the blog post:
Is there a way, from a software API, to tell the OS to commit everything to disk? For example, can calling `sync()` with every write avoid the pitfalls mentioned above?Write caching + surprise removal = badness
One potential pitfall of enabling CQ mode was that it provides cards with new opportunities to corrupt your filesystem if power is removed unexpectedly. In CQ mode, hosts should honour the requirement to maintain the card’s power supply, and only remove it after a Power-Off notification is sent; this provides an opportunity for the flash controller to commit all outstanding writes to flash. For battery-powered hosts with concealed SD slots such as a phone, that is an easy contract to fulfil — requesting device shutdown or uncovering the slot can trigger a Power-Off notification. Raspberry Pi, with its exposed SD slot and pluggable PSU, has a harder time providing this guarantee.
With multiple writes in flight, or multiple posted notifications of pending writes, we can no longer guarantee the order in which writes get committed to flash. If power is removed unexpectedly, an arbitrary collection of recent writes may not have been committed, rather than strictly the n most recent writes; this greatly complicates the task of making the filesystem resilient to corruption. The Raspberry Pi kernel sidesteps this problem by limiting the maximum number of posted writes in CQ mode to one. While in theory this may result in lower sequential write throughput, the cards I’ve tested see at most a 2–3% percent reduction in performance.
Statistics: Posted by JinShil — Thu Oct 10, 2024 12:17 am