Android文件系统日志

ext3有3个日志记录选项：日志记录、排序和写回。根据维基百科，对于崩溃恢复来说，风险从最低到最高。出于某种原因，Android版本的Linux只支持后两个选项，默认为写回。（我在跑弗罗约）

有没有办法增加对日志模式的支持？我希望在/data分区上执行此操作，该分区是ext3，也是大多数文件写入发生的地方。我的设备没有电池，所以当有人断开电源时，我需要确保它是防碰撞的

---

如果有人感兴趣，Linux选项将在kernel/fs/ext3/Kconfig中定义。具体的选项是EXT3\u DEFAULTS\u TO\u ORDERED。

解决方案是将以下内容添加到kernel/fs/EXT3/Kconfig，并使用EXT3\u DEFAULTS\u TO\u日志重建内核

choice
    prompt "EXT3 default journal mode"
    default EXT3_DEFAULTS_TO_ORDERED
    help
      The journal mode options for ext3 have different tradeoffs
      between when data is guaranteed to be on disk and
      performance.  The use of "data=writeback" can cause
      unwritten data to appear in files after an system crash or
      power failure, which can be a security issue.  However,
      "data=ordered" mode can also result in major performance
      problems, including seconds-long delays before an fsync()
      call returns.  "data=journal" is the safest option but possibly
      the the great perfromance burden.  For details, see:

      http://ext4.wiki.kernel.org/index.php/Ext3_data_mode_tradeoffs

      If you have been historically happy with ext3's performance,
      data=ordered mode will be a safe choice.


config EXT3_DEFAULTS_TO_JOURNAL
    bool "Default to 'data=journal' in ext3"
    depends on EXT3_FS
    help
      Both data and metadata are journaled.  Should be safe
      against crashes, power failure, etc.


config EXT3_DEFAULTS_TO_ORDERED
    bool "Default to 'data=ordered' in ext3"
    depends on EXT3_FS
    help
      Only metadata are journaled. Data is written first and then
      metadata is update.  Mostly safe against crashes, power
      failures, etc., except if the anomally occurred while a file 
      is being overwritten.  Most of the time files are appended and
      not over written.

config EXT3_DEFAULTS_TO_WRITEBACK
    bool "Default to 'data=writeback' in ext3"
    depends on EXT3_FS
    help
      Ext2 with a fast ckfs.  Not always safe against crashes, 
      power failure, etc., but has the best preformance

endchoice

---

我的猜测是，由于闪存的写入周期有限，他们选择不使用完整日志记录。如果你真的想耗尽你的flash，你应该能够用你想要的任何选项重新编译内核。这显然需要某种方法将内核闪存回您的设备上-这可能是也可能不是可能或容易，取决于您拥有的设备。知道如何使用完整日志选项重新编译内核吗？如上所述，Kconfig中目前只有两个选项。至于有限的写入周期，我使用的是eMMC，它确实会磨损均衡，但我同意，完整日志记录会导致更多磨损。我能够将内核闪存到设备上，因为我的公司实际上正在构建该设备。