在SSD驱动器的ext3分区“预期的行为”后突然断电的文件系统损坏?
我的公司生产一个embedded式的Debian Linux设备,可以从内置SSD驱动器上的ext3分区引导。 由于该设备是一个embedded式“黑匣子”,因此通常通过外接开关切断设备的电源,这种方式通常会被粗暴地closures。 这通常是可以的,因为ext3的日志logging保持有序,所以除了偶尔的日志文件部分丢失以外,事情一直保持顺畅。 然而,最近我们看到了许多单位,经过一些硬核循环之后,ext3分区开始出现结构性问题 – 特别是我们在ext3分区上运行e2fsck,并发现了一些类似的问题显示在本课题底部的输出列表中。 运行e2fsck直到它停止报告错误(或重新格式化分区)将清除问题。 我的问题是…在一个ext3 / SSD系统出现突然/意外关机的情况下,看到这样的问题有什么影响? 我的感觉是,这可能是我们系统中的软件或硬件问题的标志,因为我的理解是(除了一个bug或硬件问题)ext3的日志loggingfunction应该能够防止这些文件系统完整性错误。 (注意:我知道用户数据没有被logging,所以可能会发生用户文件的删除/丢失/截断;我在这里具体讨论文件系统 – 元数据错误,如下所示) 另一方面,我的同事说,这是已知的/预期的行为,因为SSD控制器有时会重新sorting写入命令,并可能导致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 '.' […]