1. 13 3月, 2009 1 次提交
  2. 20 10月, 2008 1 次提交
    • H
      ext3: add an option to control error handling on file data · 0e4fb5e2
      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 a ext3 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.
      Signed-off-by: NHidehiro Kawai <hidehiro.kawai.ez@hitachi.com>
      Cc: Jan Kara <jack@ucw.cz>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      0e4fb5e2
  3. 17 10月, 2008 1 次提交
  4. 20 10月, 2007 1 次提交
  5. 27 6月, 2006 1 次提交
  6. 12 1月, 2006 1 次提交
  7. 11 1月, 2006 1 次提交
  8. 09 1月, 2006 1 次提交
  9. 13 12月, 2005 1 次提交
  10. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4