Skip to content
  1. Jan 07, 2009
    • Frank Mayhar's avatar
      ext4: Allow ext4 to run without a journal · 0390131b
      Frank Mayhar authored
      
      
      A few weeks ago I posted a patch for discussion that allowed ext4 to run
      without a journal.  Since that time I've integrated the excellent
      comments from Andreas and fixed several serious bugs.  We're currently
      running with this patch and generating some performance numbers against
      both ext2 (with backported reservations code) and ext4 with and without
      a journal.  It just so happens that running without a journal is
      slightly faster for most everything.
      
      We did
      	iozone -T -t 4 s 2g -r 256k -T -I -i0 -i1 -i2
      
      which creates 4 threads, each of which create and do reads and writes on
      a 2G file, with a buffer size of 256K, using O_DIRECT for all file opens
      to bypass the page cache.  Results:
      
                           ext2        ext4, default   ext4, no journal
        initial writes   13.0 MB/s        15.4 MB/s          15.7 MB/s
        rewrites         13.1 MB/s        15.6 MB/s          15.9 MB/s
        reads            15.2 MB/s        16.9 MB/s          17.2 MB/s
        re-reads         15.3 MB/s        16.9 MB/s          17.2 MB/s
        random readers    5.6 MB/s         5.6 MB/s           5.7 MB/s
        random writers    5.1 MB/s         5.3 MB/s           5.4 MB/s 
      
      So it seems that, so far, this was a useful exercise.
      
      Signed-off-by: default avatarFrank Mayhar <fmayhar@google.com>
      Signed-off-by: default avatar"Theodore Ts'o" <tytso@mit.edu>
      0390131b
  2. Dec 17, 2008
  3. Nov 27, 2008
  4. Nov 26, 2008
  5. Jan 06, 2009
  6. Nov 05, 2008
    • Theodore Ts'o's avatar
      ext4: tone down ext4_da_writepages warnings · 2a21e37e
      Theodore Ts'o authored
      
      
      If the filesystem has errors, ext4_da_writepages() will return a *lot*
      of errors, including lots and lots of stack dumps.  While it's true
      that we are dropping user data on the floor, which is unfortunate, the
      stack dumps aren't helpful, and they tend to obscure the true original
      root cause of the problem.  So in the case where the filesystem has
      aborted, return an EROFS right away.
      
      Signed-off-by: default avatar"Theodore Ts'o" <tytso@mit.edu>
      2a21e37e
  7. Dec 13, 2008
    • Theodore Ts'o's avatar
      ext4: remove do_blk_alloc() · 97df5d15
      Theodore Ts'o authored
      
      
      The convenience function do_blk_alloc() is a static function with only
      one caller, so fold it into ext4_new_meta_blocks() to simplify the
      code and to make it easier to understand.
      
      To save more stack space, if count is a null pointer in
      ext4_new_meta_blocks() assume that caller wanted a single block (and
      if there is an error, no blocks were allocated).
      
      Signed-off-by: default avatar"Theodore Ts'o" <tytso@mit.edu>
      97df5d15
  8. Dec 08, 2008
    • Theodore Ts'o's avatar
      ext4: remove ext4_new_meta_block() · cfe82c85
      Theodore Ts'o authored
      
      
      There were only two one callers of the function ext4_new_meta_block(),
      which just a very simpler wrapper function around
      ext4_new_meta_blocks().  Change those two functions to call
      ext4_new_meta_blocks() directly, to save code and stack space usage.
      
      Signed-off-by: default avatar"Theodore Ts'o" <tytso@mit.edu>
      cfe82c85
  9. Jan 02, 2009
  10. Jan 07, 2009
  11. Dec 07, 2008
  12. Oct 29, 2008
  13. Oct 30, 2008
  14. Jan 05, 2009