在 Linux 2.6（实际上是 CentOS 5.3）下，我有一个文件系统，可以正常工作几分钟，然后进入只读模式，而我正尝试读取/写入数据。
它是一个扩展文件系统引用卢克斯（cryptsetup）设备通过设备映射器。luks 原始设备实际上是一个回送设备，并且该回送设备引用一个文件。该文件引用通过以下方式映射的远程系统上的文件：SSHFS。是的，很多容器。这就是我所做的，将安全备份存储到类似云的环境中，但这种环境的安全性比我喜欢的要差一些。
详细地：
- 远程系统有一个文件夹 backupFolder，其中包含一个预分配的 20G 文件 backupFile。
- 本地系统使用 sshfs 将 backupFolder 挂载到本地挂载点 backupMapped。
- 本地系统创建一个指向backupMapped/backupFile的环回设备（使用losetup）。
- 本地系统使用 cryptsetup luksOpen 将 luks 设备映射到环回设备，得到 /dev/mapper/backup。
- 本地系统将 /dev/mapper/backup 作为 ext3 设备挂载到不同的本地挂载点，例如 /root/rpg/d01
然后我可以使用同步使用本地系统上的原始数据来更新 cleartextBackup/ 上的数据。
在测试差异较小、rsync 较小的情况时，这种方法效果很好。但是对于较大的操作，在大约十五分钟看似成功的操作之后，rsync 会挂起一段时间，然后继续运行，并在源文件的其余部分生成各种错误消息：
rsync：mkstemp“/root/rpg/d01/db_pgexports/dbdump.sql”失败：只读文件系统（30）
和
rsync：无法统计目标“/root/rpg/d01/db_myexports/”：输入/输出错误（5）rsync 错误：在 main.c(493) [receiver=2.6.8] 处选择输入/输出文件、目录（代码 3）时出错
和
rsync：recv_generator：mkdir“/root/rpg/d01/vault/jjm”失败：只读文件系统 (30) rsync：stat“/root/wpg/d01/vault/jjm”失败：没有此文件或目录 (2)
我在 dmesg 中看到各种错误：
EXT3 FS on dm-12, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
Buffer I/O error on device dm-12, logical block 119212
lost page write due to I/O error on dm-12
Buffer I/O error on device dm-12, logical block 119213
lost page write due to I/O error on dm-12
Buffer I/O error on device dm-12, logical block 119214
lost page write due to I/O error on dm-12
<snip>
Buffer I/O error on device dm-12, logical block 119221
lost page write due to I/O error on dm-12
Aborting journal on device dm-12.
ext3_abort called.
EXT3-fs error (device dm-12): ext3_journal_start_sb: Detected aborted journal
Remounting filesystem read-only
EXT3-fs error (device dm-12): ext3_get_inode_loc: unable to read inode block - inode=2480641, block=4980738
EXT3-fs error (device dm-12): ext3_get_inode_loc: unable to read inode block - inode=32641, block=65538
EXT3-fs error (device dm-12): ext3_find_entry: reading directory #65281 offset 0
EXT3-fs error (device dm-12): ext3_find_entry: reading directory #65281 offset 0
EXT3-fs error (device dm-12): ext3_find_entry: reading directory #65281 offset 0
<snip>
和 /var/log/messages 中基本上相同的消息。
我认为这与超时有关（尽管它应该是读写密集型的），我对 ssh 配置参数进行了一些实验，例如
服务器存活间隔 20
服务器存活数最大为 4000
并使用 sshfs -o reconnect，甚至 -o workaround=all。
但一切都无济于事。
也许有人能解释一下到底出了什么问题，以及我该如何让这个东西可靠地保持在读写模式？
谢谢，Steve La Rocque