1. 19 Jul, 2007 1 commit
  2. 08 May, 2007 1 commit
  3. 08 Dec, 2006 1 commit
  4. 07 Dec, 2006 1 commit
    • Eric Sandeen's avatar
      [PATCH] handle ext4 directory corruption better · e6c40211
      Eric Sandeen authored
      I've been using Steve Grubb's purely evil "fsfuzzer" tool, at
      Basically it makes a filesystem, splats some random bits over it, then
      tries to mount it and do some simple filesystem actions.
      At best, the filesystem catches the corruption gracefully.  At worst,
      things spin out of control.
      As you might guess, we found a couple places in ext4 where things spin out
      of control :)
      First, we had a corrupted directory that was never checked for
      consistency...  it was corrupt, and pointed to another bad "entry" of
      length 0.  The for() loop looped forever, since the length of
      ext4_next_entry(de) was 0, and we kept looking at the same pointer over and
      over and over and over...  I modeled this check and subsequent action on
      what is done for other directory types in ext4_readdir...
      (adding this check adds some computational expense; I am testing a followup
      patch to reduce the number of times we check and re-check these directory
      entries, in all cases.  Thanks for the idea, Andreas).
      Next we had a root directory inode which had a corrupted size, claimed to
      be > 200M on a 4M filesystem.  There was only really 1 block in the
      directory, but because the size was so large, readdir kept coming back for
      more, spewing thousands of printk's along the way.
      Per Andreas' suggestion, if we're in this read error condition and we're
      trying to read an offset which is greater than i_blocks worth of bytes,
      stop trying, and break out of the loop.
      With these two changes fsfuzz test survives quite well on ext4.
      Signed-off-by: default avatarEric Sandeen <sandeen@redhat.com>
      Cc: <linux-ext4@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
  5. 11 Oct, 2006 5 commits
  6. 30 Sep, 2006 1 commit
  7. 27 Sep, 2006 3 commits
  8. 21 Apr, 2006 1 commit
  9. 28 Mar, 2006 1 commit
  10. 26 Mar, 2006 1 commit
    • Mingming Cao's avatar
      [PATCH] ext3_get_blocks: Mapping multiple blocks at a once · 89747d36
      Mingming Cao authored
      Currently ext3_get_block() only maps or allocates one block at a time.  This
      is quite inefficient for sequential IO workload.
      I have posted a early implements a simply multiple block map and allocation
      with current ext3.  The basic idea is allocating the 1st block in the existing
      way, and attempting to allocate the next adjacent blocks on a best effort
      basis.  More description about the implementation could be found here:
      The following the latest version of the patch: break the original patch into 5
      patches, re-worked some logicals, and fixed some bugs.  The break ups are:
       [patch 1] Adding map multiple blocks at a time in ext3_get_blocks()
       [patch 2] Extend ext3_get_blocks() to support multiple block allocation
       [patch 3] Implement multiple block allocation in ext3-try-to-allocate
       (called via ext3_new_block()).
       [patch 4] Proper accounting updates in ext3_new_blocks()
       [patch 5] Adjust reservation window size properly (by the given number
       of blocks to allocate) before block allocation to increase the
       possibility of allocating multiple blocks in a single call.
      Tests done so far includes fsx,tiobench and dbench.  The following numbers
      collected from Direct IO tests (1G file creation/read) shows the system time
      have been greatly reduced (more than 50% on my 8 cpu system) with the patches.
       1G file DIO write:
       	2.6.15		2.6.15+patches
       real    0m31.275s	0m31.161s
       user    0m0.000s	0m0.000s
       sys     0m3.384s	0m0.564s
       1G file DIO read:
       	2.6.15		2.6.15+patches
       real    0m30.733s	0m30.624s
       user    0m0.000s	0m0.004s
       sys     0m0.748s	0m0.380s
      Some previous test we did on buffered IO with using multiple blocks allocation
      and delayed allocation shows noticeable improvement on throughput and system
      This patch:
      Add support of mapping multiple blocks in one call.
      This is useful for DIO reads and re-writes (where blocks are already
      allocated), also is in line with Christoph's proposal of using getblocks() in
      mpage_readpage() or mpage_readpages().
      Signed-off-by: default avatarMingming Cao <cmm@us.ibm.com>
      Cc: Badari Pulavarty <pbadari@us.ibm.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
  11. 23 Mar, 2006 1 commit
    • Andrew Morton's avatar
      [PATCH] ext3_readdir: use generic readahead · d8733c29
      Andrew Morton authored
      Linus points out that ext3_readdir's readahead only cuts in when
      ext3_readdir() is operating at the very start of the directory.  So for large
      directories we end up performing no readahead at all and we suck.
      So take it all out and use the core VM's page_cache_readahead().  This means
      that ext3 directory reads will use all of readahead's dynamic sizing goop.
      Note that we're using the directory's filp->f_ra to hold the readahead state,
      but readahead is actually being performed against the underlying blockdev's
      address_space.  Fortunately the readahead code is all set up to handle this.
      Tested with printk.  It works.  I was struggling to find a real workload which
      actually cared.
      (The patch also exports page_cache_readahead() to GPL modules)
      Cc: "Stephen C. Tweedie" <sct@redhat.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
  12. 16 Apr, 2005 1 commit
    • Linus Torvalds's avatar
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds authored
      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!