我的公司生产一个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 '.' in directory inode 46948. Fix<y>? yes Directory inode 46948, block 0, offset 12: directory corrupted Salvage<y>? yes Entry 'status_2012-11-26_14h13m41.csv' in /var/log/status_logs (46956) has deleted/unused inode 47075. Clear<y>? yes Entry 'status_2012-11-26_10h42m58.csv.gz' in /var/log/status_logs (46956) has deleted/unused inode 47076. Clear<y>? yes Entry 'status_2012-11-26_11h29m41.csv.gz' in /var/log/status_logs (46956) has deleted/unused inode 47080. Clear<y>? yes Entry 'status_2012-11-26_11h42m13.csv.gz' in /var/log/status_logs (46956) has deleted/unused inode 47081. Clear<y>? yes Entry 'status_2012-11-26_12h07m17.csv.gz' in /var/log/status_logs (46956) has deleted/unused inode 47083. Clear<y>? yes Entry 'status_2012-11-26_12h14m53.csv.gz' in /var/log/status_logs (46956) has deleted/unused inode 47085. Clear<y>? yes Entry 'status_2012-11-26_15h06m49.csv' in /var/log/status_logs (46956) has deleted/unused inode 47088. Clear<y>? yes Entry 'status_2012-11-20_14h50m09.csv' in /var/log/status_logs (46956) has deleted/unused inode 47073. Clear<y>? yes Entry 'status_2012-11-20_14h55m32.csv' in /var/log/status_logs (46956) has deleted/unused inode 47074. Clear<y>? yes Entry 'status_2012-11-26_11h04m36.csv.gz' in /var/log/status_logs (46956) has deleted/unused inode 47078. Clear<y>? yes Entry 'status_2012-11-26_11h54m45.csv.gz' in /var/log/status_logs (46956) has deleted/unused inode 47082. Clear<y>? yes Entry 'status_2012-11-26_12h12m20.csv.gz' in /var/log/status_logs (46956) has deleted/unused inode 47084. Clear<y>? yes Entry 'status_2012-11-26_12h33m52.csv.gz' in /var/log/status_logs (46956) has deleted/unused inode 47086. Clear<y>? yes Entry 'status_2012-11-26_10h51m59.csv.gz' in /var/log/status_logs (46956) has deleted/unused inode 47077. Clear<y>? yes Entry 'status_2012-11-26_11h17m09.csv.gz' in /var/log/status_logs (46956) has deleted/unused inode 47079. Clear<y>? yes Entry 'status_2012-11-26_12h54m11.csv.gz' in /var/log/status_logs (46956) has deleted/unused inode 47087. Clear<y>? yes Pass 3: Checking directory connectivity '..' in /etc/network/run (46948) is <The NULL inode> (0), should be /etc/network (46953). Fix<y>? yes Couldn't fix parent of inode 46948: Couldn't find parent directory entry Pass 4: Checking reference counts Unattached inode 46945 Connect to /lost+found<y>? yes Inode 46945 ref count is 2, should be 1. Fix<y>? yes Inode 46953 ref count is 5, should be 4. Fix<y>? yes Pass 5: Checking group summary information Block bitmap differences: -(208264--208266) -(210062--210068) -(211343--211491) -(213241--213250) -(213344--213393) -213397 -(213457--213463) -(213516--213521) -(213628--213655) -(213683--213688) -(213709--213728) -(215265--215300) -(215346--215365) -(221541--221551) -(221696--221704) -227517 Fix<y>? yes Free blocks count wrong for group #6 (17247, counted=17611). Fix<y>? yes Free blocks count wrong (161691, counted=162055). Fix<y>? yes Inode bitmap differences: +(47089--47090) +47093 +47095 +(47097--47099) +(47101--47104) -(47219--47220) -47222 -47224 -47228 -47231 -(47347--47348) -47350 -47352 -47356 -47359 -(47457--47488) -47985 -47996 -(47999--48000) -48017 -(48027--48028) -(48030--48032) -48049 -(48059--48060) -(48062--48064) -48081 -(48091--48092) -(48094--48096) Fix<y>? yes Free inodes count wrong for group #6 (7608, counted=7624). Fix<y>? yes Free inodes count wrong (61919, counted=61935). Fix<y>? yes embeddedrootwrite: ***** FILE SYSTEM WAS MODIFIED ***** embeddedrootwrite: ********** WARNING: Filesystem still has errors ********** embeddedrootwrite: 657/62592 files (24.4% non-contiguous), 87882/249937 blocks Embedded-PC-failsafe:~# 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 Directory entry for '.' in ... (46948) is big. Split<y>? yes Missing '..' in directory inode 46948. Fix<y>? yes Setting filetype for entry '..' in ... (46948) to 2. Pass 3: Checking directory connectivity '..' in /etc/network/run (46948) is <The NULL inode> (0), should be /etc/network (46953). Fix<y>? yes Pass 4: Checking reference counts Inode 2 ref count is 12, should be 13. Fix<y>? yes Pass 5: Checking group summary information embeddedrootwrite: ***** FILE SYSTEM WAS MODIFIED ***** embeddedrootwrite: 657/62592 files (24.4% non-contiguous), 87882/249937 blocks Embedded-PC-failsafe:~# Embedded-PC-failsafe:~# e2fsck /dev/sda3 e2fsck 1.41.3 (12-Oct-2008) embeddedrootwrite: clean, 657/62592 files, 87882/249937 blocks 你们都错了（也许？）… ext3正在应对尽可能最好的底层存储删除如此突然。
您的SSD可能具有某种types的板载caching。 你没有提到使用SSD的品牌/型号，但这听起来像一个消费级别的SSD，而不是企业级或工业级的型号 。
无论哪种方式，caching用于帮助合并写入并延长驱动器的使用寿命。 如果有在途的写道，权力的突然丧失绝对是你腐败的根源。 真正的企业级和工业级SSD拥有超级电容器 ，能够将数据从高速caching转移到非易失性存储，并保持足够的时间，这与电池供电和闪存支持的RAID控制器caching工作方式大致相同。
如果您的驱动器没有超级terminal，则正在进行的事务正在丢失，因此文件系统损坏。 ext3可能被告知，一切都在稳定的存储，但这只是caching的function。
你是对的，你的同事是错的。 除了出错的日记，确保你永远不会有不一致的FS元数据。 您可以使用hdparm来检查驱动器的写入caching是否已启用。 如果是，并且你还没有启用IO障碍（在默认情况下closuresext3，closuresext4），那么这就是问题的原因。
需要屏障来强制驱动器写入caching在正确的时间刷新以保持一致性，但是一些驱动器performance不佳，或者报告它们的写入caching被禁用，或者静默地忽略flush命令。 这可以防止日记工作。