在產品運行過程中，數據丟失是常見的問題，尤其在頻繁寫入數據的場景中。本文將分析數據丟失的原因，并從硬件、系統和軟件優化等方面提供解決思路，幫助提升數據安全性和系統穩定性。

?丟數據情形

丟數據的問題一般發生在產品運行現場有頻繁數據寫入的情形，特別是在使用了數據庫的時候。一般有以下表現：

輕微表現：數據庫最新記錄的數據項無故丟失；

比較嚴重情況：較多記錄項數據丟失；

嚴重情形：文件名丟失或者亂碼；

非常嚴重情形：系統文件丟失，或者整個/opt分區無數據。

?丟數據原因及解決思路

丟數據的表現非常復雜，還有更多其它表現。究其原因，不外乎硬件方面、驅動層面以及應用程序設計等幾個方面。

像硬件部分，電源是重中之重，驅動層面的話，穩健可靠的驅動程序是至關重要的。但僅僅做好這兩方面，如果應用軟件沒進行系統優化或者數據處理優化，同樣也會帶來丟數據的風險。下面分別從這幾方面來做一些闡述。

1. 基本思路：硬件設計+系統設計+軟件優化

穩定可靠的電源，掉電檢測電路，后備電源，系統設計的掉電檢測設計，應用程序對掉電的響應，以及平時的數據冗余備份等措施。

首先，電源穩定是產品穩定的基礎。如果沒穩定的電源，談產品的可靠性和穩定性都是空中樓閣，無從談起。所以，務必設計穩定可靠的電源，包括電源的功率、對紋波的抑制等。穩定的電源解決的是產品正常工作時候的供電問題，這樣能避免很多隱蔽性很強的問題。

如果現場電源異常斷電無法克服，就可以考慮增加備用電源，同時增加主電源的掉電檢測電路，系統檢測到電源掉電后，進行數據方面的處理，確保已經寫入緩存的數據能及時寫入到磁盤中，保證數據的完整性。這需要硬件、系統驅動以及應用程序幾方面配合才能達到目的。

如果運行時產生的數據非常關鍵，特別是涉及到支付的數據，建議對數據進行冗余備份保護。如果本地存儲空間允許，可以在本地進行雙備份；如果系統聯網，可以通過網絡方式將數據發送到遠程服務器進行實時備份，這種方式非常安全；當然如果有云存儲功能，將數據實時存放云端也是非常安全的。如果進行了實時數據遠程備份，那異常掉電對數據的影響就非常小了。

2. 解決現場丟數據的問題，需要從硬件、驅動、應用設計多方面入手才能妥善解決

2.1 選擇合適的文件系統

不同的存儲介質需要適配不同的文件系統，在嵌入式設備中常用的存儲器是NAND Flash和eMMC。

適合NAND Flash的文件系統是UBIFS和YAFFS2。UBIFS和YAFFS2的不同之處在于它們的存儲方式、性能、垃圾回收機制和應用場景：

2.1.1 存儲方式

UBIFS是基于塊存儲的，而YAFFS2是基于頁存儲的。YAFFS2將文件數據劃分為固定大小的頁，可以更好地適應NAND Flash的物理特性，減少存儲空間的浪費，提高了存儲空間的利用率。而塊的大小通常比頁大，這意味著UBIFS可以更有效地管理存儲空間。與YAFFS2相比，UBIFS使用的塊更大，從而減少了存儲空間的浪費和碎片化的可能性。另一方面，UBIFS的塊存儲機制可以適應不同大小和容量的閃存設備，并能根據實際需求進行動態調整，具備更好的可擴展性和靈活性。

2.1.2 性能方面

UBIFS支持write-back，其寫入的數據會被cache，直到有必要寫入時才寫到flash，可以大大地降低分散小區塊數量并提高I/O效率。YAFFS2則是實時寫入，這會影響一部分I/O性能，但由于頁是YAFFS2最小的存儲單位，所以YAFFS2可以迅速定位到特定的頁，并只讀取或寫入所需的數據，而不需要處理整個文件。這種局部性的訪問方式可以減少不必要的讀取和寫入操作。

2.13 垃圾回收機制方面

UBIFS是基于日志型的垃圾回收，日志的垃圾回收機制提供了一種原子性和一致性的保證。所有的文件更新操作首先會被記錄到日志區域，而不是直接寫入到主存儲區域。只有當這些更新操作被成功記錄到日志后，才會進行實際的數據更新。這種方式確保了在更新操作過程中出現意外中斷或系統崩潰時，文件系統能夠恢復到一致的狀態。

其次，日志型的垃圾回收機制實際的數據更新是異步進行的，即不會每次都同步到flash，因此寫操作的延遲被顯著降低，同時也減少了閃存擦除的次數。這種設計使得UBIFS在面對大量的寫操作時能夠保持較高的性能。

YAFFS2使用段式的垃圾回收。當文件系統中的數據被修改或刪除時，會標記相應的段為無效或可回收。段式回收的過程包括掃描這些無效的段，并將其中的數據進行擦除和回收，以便重新利用這些存儲空間。

段式回收的好處是可以批量處理無效數據，提高垃圾回收的效率。相對于基于頁的回收機制，段式回收減少了對閃存的頻繁擦除操作，從而延長了閃存的使用壽命。此外，由于回收操作是在段的級別上進行的，它能夠更有效地管理存儲空間，減少了存儲碎片化的可能性。

2.1.4 在應用場景上

UBIFS更適合大容量存儲系統，而YAFFS2更適用于中小容量的NAND Flash存儲設備。

適合eMMC的文件系統是FAT32和Ext4。其差異主要體現在兼容性、性能、安全性和磁盤空間利用這幾個方面：

兼容性方面：FAT32是一個較老的文件系統，但它具有廣泛的兼容性，被大多數操作系統支持。而Ext4是Linux下的一個文件系統，不支持Windows。

性能方面：FAT32不支持單個大于4GB的文件，一旦超過容量限制，系統就會提示磁盤空間不足。另外，FAT32不支持軟鏈接文件，所有在FAT32中的軟鏈接文件都會失效，這些方面在一定程度上影響了其性能。而相比之下，EXT4則沒有上述問題，有更好的性能表現。

安全性方面：FAT32不支持磁盤配額，安全性能較低。而EXT4可以進行加密、修改、運行、讀取目錄及寫入權限的設置，提高了文件系統的安全性。

磁盤空間利用方面：FAT32的磁盤利用率相對較低，尤其是在分區大小較大時，其簇的大小也會變得相對較大，從而降低了磁盤空間的利用率。而EXT4則能夠更有效地利用磁盤空間，提高了存儲效率。

選擇哪個文件系統取決于具體的應用場景和需求。

對于NAND Flash，如果存儲器容量較大且能保證設備長期運行的情況下，UBIFS是個很好的選擇。如果設備需要經常讀寫文件，且存在偶發性斷電，則YAFFS2更合適。

對于eMMC來說，如果需要廣泛的兼容性和簡單的操作，FAT32可能是一個不錯的選擇。然而，在需要更高的性能、安全性和穩定性時，EXT4可能更適合。

2.2 系統掛載方式

在Linux系統下必須先掛載對應設備，然后才能被訪問，掛載方式有很多，包括同步掛載（sync）、異步掛載（async）、只讀掛載（ro）、讀寫掛載（rw）等，不同的掛載方式會直接影響系統的功能與性能：

async方式掛載中，所有涉及文件系統I/O的操作都是異步處理，即數據不會同步寫入到磁盤，而是寫入到緩沖區中，這種設置會提高系統的性能，但同時也會降低數據的安全性，一般在生產環境下不推薦使用。除非對性能要求很高，對數據可靠性要求不高的場景。

sync 與async相反，即有I/O操作時，都會同步處理I/O，把數據同步寫入硬盤，此參數會犧牲一部分I/O性能，但是換來的是系統突發宕機后數據的安全性。

ro為只讀掛載，可以有效保護分區中的內容，防止分區中的文件被刪除和修改。

rw為讀寫掛載，可以修改分區內容。

Linux在使用mount命令掛載時，如果不指定掛載參數，其默認的掛載方式為異步可讀寫方式，如果需要使用其它掛載方式，可以通過“-o”參數指定，例如：

[root@user~]# mount-o ro/dev/mmcblk0p2/mnt //只讀掛載

如果修改掛載方式，可以使用“-o remount”來指定，多個掛載參數可以用“,”隔開：

[root@user~]# mount-o remount,rw/dev/mmcblk0p2/mnt //重新掛載為可讀寫方式

如果需要修改系統的自動掛載方式，可以通過在/etc/fstab文件下添加對分區的掛載描述，fstab文件內容如下：

[root@user:~]# cat /etc/fstab#stock fstab - you probably want to override this with a machine specific one/dev/root / auto defaults 1 1proc /proc proc defaults 0 0devpts /dev/pts devpts mode=0620,gid=5 0 0usbdevfs /proc/bus/usb usbdevfs noauto 0 0tmpfs /run tmpfs mode=0755,nodev,nosuid,strictatime 0 0tmpfs /var/volatile tmpfs defaults,size=50M 0 0tmpfs /media/ram tmpfs defaults,size=16M 0 0

其中，第4列為對應分區的掛載方式（類似于mount -o），可以通過修改該列來實現不同掛載方式。