1. 14 10月, 2008 1 次提交
  2. 13 10月, 2008 3 次提交
  3. 12 10月, 2008 1 次提交
  4. 11 10月, 2008 4 次提交
    • H
      ext4: add an option to control error handling on file data · 5bf5683a
      Hidehiro Kawai 提交于
      If the journal doesn't abort when it gets an IO error in file data
      blocks, the file data corruption will spread silently.  Because
      most of applications and commands do buffered writes without fsync(),
      they don't notice the IO error.  It's scary for mission critical
      systems.  On the other hand, if the journal aborts whenever it gets
      an IO error in file data blocks, the system will easily become
      inoperable.  So this patch introduces a filesystem option to
      determine whether it aborts the journal or just call printk() when
      it gets an IO error in file data.
      
      If you mount an ext4 fs with data_err=abort option, it aborts on file
      data write error.  If you mount it with data_err=ignore, it doesn't
      abort, just call printk().  data_err=ignore is the default.
      
      Here is the corresponding patch of the ext3 version:
      http://kerneltrap.org/mailarchive/linux-kernel/2008/9/9/3239374Signed-off-by: NHidehiro Kawai <hidehiro.kawai.ez@hitachi.com>
      Signed-off-by: NTheodore Ts'o <tytso@mit.edu>
      5bf5683a
    • H
      jbd2: don't dirty original metadata buffer on abort · 7ad7445f
      Hidehiro Kawai 提交于
      Currently, original metadata buffers are dirtied when they are
      unfiled whether the journal has aborted or not.  Eventually these
      buffers will be written-back to the filesystem by pdflush.  This
      means some metadata buffers are written to the filesystem without
      journaling if the journal aborts.  So if both journal abort and
      system crash happen at the same time, the filesystem would become
      inconsistent state.  Additionally, replaying journaled metadata
      can overwrite the latest metadata on the filesystem partly.
      Because, if the journal gets aborted, journaled metadata are
      preserved and replayed during the next mount not to lose
      uncheckpointed metadata.  This would also break the consistency
      of the filesystem.
      
      This patch prevents original metadata buffers from being dirtied
      on abort by clearing BH_JBDDirty flag from those buffers.  Thus,
      no metadata buffers are written to the filesystem without journaling.
      Signed-off-by: NHidehiro Kawai <hidehiro.kawai.ez@hitachi.com>
      Signed-off-by: NTheodore Ts'o <tytso@mit.edu>
      7ad7445f
    • H
      ext4: add checks for errors from jbd2 · 7ffe1ea8
      Hidehiro Kawai 提交于
      If the journal has aborted due to a checkpointing failure, we
      have to keep the contents of the journal space.  Otherwise, the
      filesystem will lose uncheckpointed metadata completely and
      become inconsistent.  To avoid this, we need to keep needs_recovery
      flag if checkpoint has failed.
      
      With this patch, ext4_put_super() detects a checkpointing failure
      from the return value of journal_destroy(), then it invokes
      ext4_abort() to make the filesystem read only and keep
      needs_recovery flag.  Errors from jbd2_journal_flush() are also
      handled by this patch in some places.
      Signed-off-by: NHidehiro Kawai <hidehiro.kawai.ez@hitachi.com>
      Signed-off-by: NTheodore Ts'o <tytso@mit.edu>
      7ffe1ea8
    • H
      jbd2: fix error handling for checkpoint io · 44519faf
      Hidehiro Kawai 提交于
      When a checkpointing IO fails, current JBD2 code doesn't check the
      error and continue journaling.  This means latest metadata can be
      lost from both the journal and filesystem.
      
      This patch leaves the failed metadata blocks in the journal space
      and aborts journaling in the case of jbd2_log_do_checkpoint().
      To achieve this, we need to do:
      
      1. don't remove the failed buffer from the checkpoint list where in
         the case of __try_to_free_cp_buf() because it may be released or
         overwritten by a later transaction
      2. jbd2_log_do_checkpoint() is the last chance, remove the failed
         buffer from the checkpoint list and abort the journal
      3. when checkpointing fails, don't update the journal super block to
         prevent the journaled contents from being cleaned.  For safety,
         don't update j_tail and j_tail_sequence either
      4. when checkpointing fails, notify this error to the ext4 layer so
         that ext4 don't clear the needs_recovery flag, otherwise the
         journaled contents are ignored and cleaned in the recovery phase
      5. if the recovery fails, keep the needs_recovery flag
      6. prevent jbd2_cleanup_journal_tail() from being called between
         __jbd2_journal_drop_transaction() and jbd2_journal_abort()
         (a possible race issue between jbd2_log_do_checkpoint()s called by
         jbd2_journal_flush() and __jbd2_log_wait_for_space())
      Signed-off-by: NHidehiro Kawai <hidehiro.kawai.ez@hitachi.com>
      Signed-off-by: NTheodore Ts'o <tytso@mit.edu>
      44519faf
  5. 13 10月, 2008 1 次提交
    • H
      jbd2: abort when failed to log metadata buffers · 77e841de
      Hidehiro Kawai 提交于
      If we failed to write metadata buffers to the journal space and
      succeeded to write the commit record, stale data can be written
      back to the filesystem as metadata in the recovery phase.
      
      To avoid this, when we failed to write out metadata buffers,
      abort the journal before writing the commit record.
      
      We can also avoid this kind of corruption by using the journal
      checksum feature because it can detect invalid metadata blocks in the
      journal and avoid them from being replayed.  So we don't need to care
      about asynchronous commit record writeout with a checksum.
      Signed-off-by: NHidehiro Kawai <hidehiro.kawai.ez@hitachi.com>
      Signed-off-by: NTheodore Ts'o <tytso@mit.edu>
      77e841de
  6. 11 10月, 2008 2 次提交
  7. 10 10月, 2008 1 次提交
    • L
      Don't allow splice() to files opened with O_APPEND · efc968d4
      Linus Torvalds 提交于
      This is debatable, but while we're debating it, let's disallow the
      combination of splice and an O_APPEND destination.
      
      It's not entirely clear what the semantics of O_APPEND should be, and
      POSIX apparently expects pwrite() to ignore O_APPEND, for example.  So
      we could make up any semantics we want, including the old ones.
      
      But Miklos convinced me that we should at least give it some thought,
      and that accepting writes at arbitrary offsets is wrong at least for
      IS_APPEND() files (which always have O_APPEND set, even if the reverse
      isn't true: you can obviously have O_APPEND set on a regular file).
      
      So disallow O_APPEND entirely for now.  I doubt anybody cares, and this
      way we have one less gray area to worry about.
      Reported-and-argued-for-by: NMiklos Szeredi <miklos@szeredi.hu>
      Acked-by: NJens Axboe <ens.axboe@oracle.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      efc968d4
  8. 09 10月, 2008 27 次提交