Ведение журнала файловой системы Android

ext3 имеет 3 варианта ведения журнала: журнал, заказ и обратная запись. Согласно записи в Википедии, они варьируются от наименее до наиболее рискованных для восстановления после сбоя. По какой-то причине версия Linux для Android поддерживает только два последних варианта и по умолчанию использует обратную запись. (Я управляю Фройо)

Есть ли способ добавить поддержку режима журнала? Я хотел бы сделать это в разделе /data, который является ext3, а также там, где происходит большая часть записи файлов. В моем устройстве нет аккумулятора, поэтому мне нужно убедиться, что оно не выйдет из строя, когда кто-то отключит питание.

Если кому-то интересно, параметры Linux определены в файле kernel/fs/ext3/Kconfig. Конкретный параметр — EXT3_DEFAULTS_TO_ORDERED.


person Ravi    schedule 20.09.2011    source источник
comment
Я предполагаю, что они решили не использовать полное журналирование из-за ограниченного количества циклов записи флэш-памяти. Если вы действительно хотите изнашивать свою флэш-память, вы должны иметь возможность перекомпилировать ядро ​​​​с любыми параметрами, которые вы хотите. Это, очевидно, требует какого-то способа прошить ядро ​​​​обратно на ваше устройство, что может быть или не быть возможным или простым, в зависимости от того, какое у вас устройство.   -  person JesusFreke    schedule 20.09.2011
comment
Есть идеи, как перекомпилировать ядро ​​с опцией полного журнала? Как отмечалось выше, на данный момент в Kconfig есть только две опции. Что касается ограниченных циклов записи, я использую eMMC, которая выравнивает износ, но я согласен, что полное ведение журнала приведет к большему износу. Я могу прошить ядро ​​на устройство, так как моя компания на самом деле собирает устройство.   -  person Ravi    schedule 20.09.2011


Ответы (1)


Решение состояло в том, чтобы добавить следующее в kernel/fs/ext3/Kconfig и пересобрать ядро ​​с помощью EXT3_DEFAULTS_TO_JOURNAL.

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
person Ravi    schedule 22.02.2012