SSD驱动器的ext3分区上的突然掉电后文件系统损坏是“预期行为”吗?
我公司制造了一个嵌入式Debian Linux设备,该设备从内部SSD驱动器上的ext3分区启动。因为该设备是嵌入式“黑匣子”,所以通常通过简单地通过外部开关切断设备电源来粗鲁地关闭它。 这通常是可以的,因为ext3的日志记录可以使事情井井有条,因此,除了偶尔丢失部分日志文件外,事情还可以继续进行。 但是,我们最近看到了许多单元,在经过多次硬重启之后,ext3分区开始出现结构性问题-特别是,我们在ext3分区上运行e2fsck,它发现了许多类似的问题显示在此问题底部的输出清单中。运行e2fsck直到停止报告错误(或重新格式化分区),都可以解决问题。 我的问题是...在遭受大量突然/意外关机的ext3 / SSD系统上看到类似问题的含义是什么? 我的感觉是这可能是我们系统中软件或硬件问题的迹象,因为我的理解是ext3的日记功能(除非存在错误或硬件问题)被认为可以防止这类文件系统完整性错误。(注意:我了解用户数据未记录日志,因此用户文件可能被蒙蒙/丢失/截断;我在这里专门谈论文件系统元数据错误,如下所示) 另一方面,我的同事说这是已知的/预期的行为,因为SSD控制器有时会重新排序写命令,这可能会使ext3日志感到困惑。特别是,他认为,即使给定了正常运行的硬件和无错误的软件,ext3日志也只会减少文件系统损坏的可能性,这并非不可能,因此我们不时看到这样的问题也不会感到惊讶。 我们哪个是对的? Embedded-PC-failsafe:~# ls Embedded-PC-failsafe:~# umount /mnt/unionfs Embedded-PC-failsafe:~# e2fsck /dev/sda3 e2fsck 1.41.3 (12-Oct-2008) embeddedrootwrite contains a file system with errors, check forced. Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure Invalid inode number for '.' in directory inode …