我有一些运行 American Megatrends bios 的嵌入式板，以嵌入式 linux 作为操作系统。我的问题是工业闪存 ide 会在断电时损坏。我将它们格式化为 ext4。每当发生这种情况时，我通常可以使用 fsck 修复闪存，但这在我们的部署中是不可能的。我听说禁用写缓存应该会有所帮助，但我不知道该怎么做。另外，还有什么我应该做的吗？
更多信息
该驱动器是一个 4GB ide 闪存模块。我有一个分区是 ext4。操作系统安装在该分区上，grub 是我的引导加载程序。
fdisk -l 显示 /dev/sda 作为我的闪存模块，/dev/sda1 作为我的主分区。
断电后，我通常无法完全通过启动初始化脚本来实现。
当我在另一台 PC 上安装驱动器时，我运行 fsck /dev/sda1。它总是显示类似的消息
"zero datetime on node 1553 ... fix (y)?"
我修复了它们，它可以正常启动，直到下一次断电。
明天到办公室时，我会贴出 fdisk -l 的实际输出
这就是我对系统如何工作的全部了解。我不是系统专家，我是一名软件工程师，习惯于陷入工作描述之外的困境。我知道如何格式化驱动器、安装引导加载程序、编写软件以及破解操作系统。
这是 dumpe2fs 的输出
#sudo dumpe2fs /dev/sda1
dumpe2fs 1.41.12 (17-May-2010)
Filesystem volume name: VideoServer
Last mounted on: /
Filesystem UUID: 9cba62b0-8038-4913-be30-8eb211b23d78
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: ext_attr resize_inode dir_index filetype …我的嵌入式 linux 设备使用 SD 卡来保存某些诊断数据，对于内部闪存来说太丰富了。
问题是如果设备意外关闭，卡上的文件系统 (FAT32) 已损坏。
没有办法防止意外断电或用户那样关闭它，并且设备应该是相对免维护的。更糟糕的是，数据是连续写入的，因此损坏非常频繁，Linux 在检测到故障 FS 时会以只读方式静默重新挂载它。
您建议采用哪些方法来缓解这种情况？启动时自动运行 fsck.vfat 就足够了吗？
更多信息：
我正在使用 FastCGI 在 nginx 后面运行 Django。我发现在发送给客户端的一些响应中，响应中间发生了随机数据损坏（中间可能有几百个字节左右）。
在这一点上，我已将其范围缩小为 nginx 的 FastCGI 处理程序或 Django 的 FastCGI 处理程序中的错误（即可能是 flup 中的错误），因为当我在独立（即runserver）模式下运行 Django 服务器时，从未发生此问题。它只发生在 FastCGI 模式下。
其他有趣的趋势：
它往往发生在较大的响应上。当客户端第一次登录时，它们会被发送一堆 1MB 块以将它们同步到服务器数据库。在第一次同步之后，响应要小得多（通常一次只有几 KB）。损坏似乎总是发生在开始时发送的那些 1MB 块上。
当客户端通过 LAN 连接到服务器（即低延迟、高带宽连接）时，这种情况发生得更频繁。这让我觉得在 nginx 或 flup 中存在某种竞争条件，并且会因数据速率的增加而加剧。
现在，我不得不通过在响应标头中放置一个额外的 SHA1 摘要来解决这个问题，并让客户端拒绝标头与正文校验和不匹配的响应，但这是一种可怕的解决方案。
有没有其他人经历过这样的事情，或者有任何关于如何确定是 flup 还是 nginx 有问题的指示，以便我可以向适当的团队提交错误？
在此先感谢您的帮助。
注意：我也在 lighttpd + FastCGI + Django 中发布了一个类似的错误：https : //stackoverflow.com/questions/3714489/lighttpd-fastcgi-django-truncated-response-sent-to-client-due-to - 出乎意料......即使这不是一回事（截断与损坏），它开始看起来像共同的罪魁祸首是 flup / Django 而不是 web 服务器..
编辑：我还应该注意我的环境是什么：
Mac Mini 上的 OSX 10.6.6
Python 2.6.1（系统）
Django 1.3（来自官方压缩包）
flup 1.0.2（来自 flup 站点上的 Python …
Linux 系统有时会将根文件系统重新挂载为只读，例如，如果出现 I/O 错误。
我的机器在发生这种情况时变得毫无用处，最终我手动重新启动它。
有没有办法让 Linux 在发生这种情况时自动重新启动？只读挂载对我来说毫无用处。
我将在一些大型文件系统（大约 50 TB）上测试“xfs_repair”，因为过去内存使用率很高。虽然我只能在正确的文件系统上测试程序，但最好在损坏的系统上测试它们。
那么破坏文件系统的最佳方法是什么。如果该方法每次都重复出现相同的损坏，则额外加分....
让人们了解我在 2006 年的意思
“要在多 TB 文件系统上成功检查或运行修复，您需要：
xfs_repair 通常会使用比这更少的内存，但是这些数字为您提供了一个大概的数字，了解一个大于 80% 的大型文件系统需要修复的内存。
FWIW，上次在内部出现这种情况时，有问题的 29TB 文件系统需要约 75GB 的 RAM+swap 才能修复。”
我有一台运行 Maverick 的笔记本电脑（很高兴直到昨天），还有一个 Patriot Torx SSD；整个分区的LUKS加密；一个 lvm 物理卷；然后在 ext4 逻辑卷中 home 和 root。
当我昨天尝试启动它时，它抱怨无法挂载根文件系统。运行fsck，基本上每个inode好像都出错了。主文件系统和根文件系统都显示出类似的问题。检查备份超级块无济于事。
e2fsck 1.41.12 (17-May-2010)
lithe_root was not cleanly unmounted, check forced.
Resize inode not valid. Recreate? no
Pass 1: Checking inodes, blocks, and sizes
Root inode is not a directory. Clear? no
Root inode has dtime set (probably due to old mke2fs). Fix? no
Inode 2 is in use, but has dtime set. Fix? no
Inode 2 has a extra size (4730) which is invalid
Fix? no …今天我想增加一个虚拟机的大小，所以我做了我一直在做的事情（以前做过）：
qemu-img resize diskimage.qcow2 +22GB
然后文件损坏了，VM 不再启动。我尝试从 CD 启动 VM 以调整分区，但系统将不再读取磁盘：
qemu-img check -r all diskimage.qcow2
tcmalloc: large alloc 389841715200 bytes == (nil) @ 0x7fdb4ea66bf3 0x7fdb4ea88488 0x7fdb4e5674a6 0x7fdb50236a37 0x7fdb50236bc8 0x7fdb50237011 0x7fdb5023941e 0x7fdb5023d891 0x7fdb5027848b 0x7fdb5027c196 0x7fdb491efb35 0x7fdb5021ee4d (nil)
No errors were found on the image.
没有错误？听起来不错，但virsh start vm不起作用，日志说：
2017-05-21T10:02:30.755824Z qemu-system-x86_64: -drive file=/.../diskimage.qcow2,format=qcow2,if=none,id=drive-virtio-disk0: could not open disk image /.../diskimage.qcow2: qcow2: Image is corrupt; cannot be opened read/write
我尝试转换为 raw 但转换失败（退出 1）：
qemu-img convert -f qcow2 diskimage.qcow2 -O raw diskimage.raw
qcow2: …我已经使用了几种不同的工具来修复磁盘，并且一直想知道是否有一份 CHKDSK 可以修复的确切内容列表？MFT？引导扇区？备份引导扇区？集群？哪些常见的问题不能修复它？
这是噩梦般的日子之一：运行在 Linux SW-RAID1 上的虚拟化服务器运行的虚拟机在看似随机的代码块中表现出随机段错误。
在调试时，我发现一个文件在每次运行时都会给出不同的 md5sum。深入挖掘，我发现：组成 RAID1 镜像的原始磁盘分区包含 2 个位差异和 ca。一张盘上的 9 个扇区完全为空，而另一张盘上则充满了数据。
显然，Linux 从镜像集的不确定选择的磁盘中返回一个扇区。所以有时相同的扇区返回正常，有时损坏的返回。
该文件说：
RAID 不能也不应该防止介质上的数据损坏。因此，故意损坏磁盘上的数据（例如使用 dd）以查看 RAID 系统将如何处理也没有任何意义。很有可能（除非您损坏 RAID 超级块）RAID 层永远不会发现损坏，但您在 RAID 设备上的文件系统将被损坏。
谢谢。那会帮助我入睡。:-/
有没有办法让 Linux 至少通过使用扇区校验和或类似的东西来检测这种损坏？这会在 RAID5 设置中检测到吗？这是我希望我使用 ZFS 或 btrfs 的时刻吗（一旦它在没有超级管理员功能的情况下变得可用）？
编辑：我并不孤单。
AFAIK文件系统损坏的原因如下：
问题：
dd，但还有比这更多的东西吗？我对 Linux 很好奇，但这可能也适用于 Windows。