在嵌入式環境中同步還是不同步？

我有一個在一塊快閃記憶體上執行 Debian 10 的單板設備。使用 UBIFS，並將其分為兩個卷：一個 ro 根和一個 rw /var。我發現在電源循環/重置條件下，我可以得到 0 字節文件。我將我的“設置”保存在 /var/opt/myApp 中。將 /var 的掛載選項更改為包含sync似乎會使這些事件消失。

我知道通常的建議是非同步優於同步，但通常會用“通常，但並非總是”來警告它，幾乎沒有解釋異常可能是什麼。

另一種解決方案是修改我將數據寫入磁碟的所有呼叫站點，不僅在文件關閉時刷新，而且同步（我用python做了很多）。從編碼/完整性的角度來看，安裝sync似乎既減少了工作量，又避免了我錯過在某些地方添加同步防護，因為它是通用的。

此外，我允許設備將數據保存到 USB 拇指驅動器。我想我也應該安裝這些同步，以減少在將數據寫入它們後立即將它們拉出時的損失。

這是一個適當的特殊配置來證明使用的合理性sync嗎？還是我應該使用替代解決方案？

這是我的意見：抱歉提前冗長。

當我們具體談論時，ubifs我們應該總是sync選擇/類似的選項。

ubifs支持write-back caching

這意味著寫入文件的更改不會直接寫入快閃記憶體。它們首先儲存在頁面記憶體中，然後寫入快閃記憶體。（閱讀有關write buffersUBIFS 中 NAND 快閃記憶體的更多資訊）

這通過減少寫入次數來提高文件系統性能。

請注意，這是asynchronousfs 的行為。

正如您在問題中所說，當您使用 -sync 選項安裝 UBIFS 時，它會使文件系統synchronous（每次更改都寫入快閃記憶體）但是以性能下降為代價。

如果您正在使用asynchronous像 ubifs 這樣的文件系統，那麼確保將寫入寫入快閃記憶體的責任在於應用程序開發人員。這是 write(2) 的手冊頁所說的：

$ man 2 write
NOTES
  A  successful return from write() does not make any guarantee that data
  has been committed to disk.  In fact, on some buggy implementations, it
  does  not  even guarantee that space has successfully been reserved for
  the data.  The only way to be sure is to call fsync(2)  after  you  are
  done writing all your data.

使用

sync- 同步整個 fs。可能不是最優的

fsync- 主要做這項工作

fdatasync- 僅刷新數據更改而不刷新元數據（權限）。比可能更優化fsync（不確定）

另請閱讀有關 fsync 的 Good Read

所以最後，你的選擇：

1. 使用“同步”掛載 - 性能受到影響
2. 使用上述sync選項改進應用程序。
3. 在應用程序中處理 0 字節文件
4. 創建臨時文件並稍後重命名它們

最後一個想法，可能想切換到同步 fs 之類的jffs2（如果使用 NAND 快閃記憶體，則不是完全同步的）。我知道這不是您問題的答案，但是，寫了這麼多還不如寫這個….

引用自：https://unix.stackexchange.com/questions/537965