1. 12 10月, 2006 2 次提交
  2. 27 9月, 2006 5 次提交
  3. 28 8月, 2006 1 次提交
  4. 01 7月, 2006 1 次提交
  5. 26 6月, 2006 2 次提交
    • M
      [PATCH] ext3_fsblk_t: the rest of in-kernel filesystem blocks conversion · 43d23f90
      Mingming Cao 提交于
      Convert the ext3 in-kernel filesystem blocks to ext3_fsblk_t.  Convert the
      rest of all unsigned long type in-kernel filesystem blocks to ext3_fsblk_t,
      and replace the printk format string respondingly.
      Signed-off-by: NMingming Cao <cmm@us.ibm.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      43d23f90
    • M
      [PATCH] ext3_fsblk_t: filesystem, group blocks and bug fixes · 1c2bf374
      Mingming Cao 提交于
      Some of the in-kernel ext3 block variable type are treated as signed 4 bytes
      int type, thus limited ext3 filesystem to 8TB (4kblock size based).  While
      trying to fix them, it seems quite confusing in the ext3 code where some
      blocks are filesystem-wide blocks, some are group relative offsets that need
      to be signed value (as -1 has special meaning).  So it seem saner to define
      two types of physical blocks: one is filesystem wide blocks, another is
      group-relative blocks.  The following patches clarify these two types of
      blocks in the ext3 code, and fix the type bugs which limit current 32 bit ext3
      filesystem limit to 8TB.
      
      With this series of patches and the percpu counter data type changes in the mm
      tree, we are able to extend exts filesystem limit to 16TB.
      
      This work is also a pre-request for the recent >32 bit ext3 work, and makes
      the kernel to able to address 48 bit ext3 block a lot easier: Simply redefine
      ext3_fsblk_t from unsigned long to sector_t and redefine the format string for
      ext3 filesystem block corresponding.
      
      Two RFC with a series patches have been posted to ext2-devel list and have
      been reviewed and discussed:
      http://marc.theaimsgroup.com/?l=ext2-devel&m=114722190816690&w=2
      
      http://marc.theaimsgroup.com/?l=ext2-devel&m=114784919525942&w=2
      
      Patches are tested on both 32 bit machine and 64 bit machine, <8TB ext3 and
      >8TB ext3 filesystem(with the latest to be released e2fsprogs-1.39).  Tests
      includes overnight fsx, tiobench, dbench and fsstress.
      
      This patch:
      
      Defines ext3_fsblk_t and ext3_grpblk_t, and the printk format string for
      filesystem wide blocks.
      
      This patch classifies all block group relative blocks, and ext3_fsblk_t blocks
      occurs in the same function where used to be confusing before.  Also include
      kernel bug fixes for filesystem wide in-kernel block variables.  There are
      some fileystem wide blocks are treated as int/unsigned int type in the kernel
      currently, especially in ext3 block allocation and reservation code.  This
      patch fixed those bugs by converting those variables to ext3_fsblk_t(unsigned
      long) type.
      Signed-off-by: NMingming Cao <cmm@us.ibm.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      1c2bf374
  6. 27 3月, 2006 3 次提交
  7. 24 3月, 2006 1 次提交
  8. 12 1月, 2006 1 次提交
  9. 11 1月, 2006 1 次提交
  10. 09 11月, 2005 1 次提交
  11. 31 10月, 2005 2 次提交
    • B
      [PATCH] ext3: sparse fixes · 381be254
      Ben Dooks 提交于
      Fix warnings from sparse due to un-declared functions that should either
      have a header file or have been declared static
      
       fs/ext2/bitmap.c:14:15: warning: symbol 'ext2_count_free' was not declared. Should it be static?
       fs/ext2/namei.c:92:15: warning: symbol 'ext2_get_parent' was not declared. Should it be static?
       fs/ext3/bitmap.c:15:15: warning: symbol 'ext3_count_free' was not declared. Should it be static?
       fs/ext3/namei.c:1013:15: warning: symbol 'ext3_get_parent' was not declared. Should it be static?
       fs/ext3/xattr.c:214:1: warning: symbol 'ext3_xattr_block_get' was not declared. Should it be static?
       fs/ext3/xattr.c:358:1: warning: symbol 'ext3_xattr_block_list' was not declared. Should it be static?
       fs/ext3/xattr.c:630:1: warning: symbol 'ext3_xattr_block_find' was not declared. Should it be static?
       fs/ext3/xattr.c:863:1: warning: symbol 'ext3_xattr_ibody_find' was not declared. Should it be static?
      Signed-off-by: NBen Dooks <ben-linux@fluff.org>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      381be254
    • G
      [PATCH] Locking problems while EXT3FS_DEBUG on · 5b116879
      Glauber de Oliveira Costa 提交于
      I noticed some problems while running ext3 with the debug flag set on.
      More precisely, I was unable to umount the filesystem.  Some investigation
      took me to the patch that follows.
      
      At a first glance , the lock/unlock I've taken out seems really not
      necessary, as the main code (outside debug) does not lock the super.  The
      only additional danger operations that debug code introduces seems to be
      related to bitmap, but bitmap operations tends to be all atomic anyway.
      
      I also took the opportunity to fix 2 spelling errors.
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      5b116879
  12. 23 9月, 2005 1 次提交
  13. 29 6月, 2005 1 次提交
    • M
      [PATCH] ext3: reduce allocate-with-reservation lock latencies · 21fe3471
      Mingming Cao 提交于
      Currently in ext3 block reservation code, the global filesystem reservation
      tree lock (rsv_block) is hold during the process of searching for a space
      to make a new reservation window, including while scaning the block bitmap
      to verify if the avalible window has a free block.  Holding the lock during
      bitmap scan is unnecessary and could possibly cause scalability issue and
      latency issues.
      
      This patch tries to address this by dropping the lock before scan the
      bitmap.  Before that we need to reserve the open window in case someone
      else is targetting at the same window.  Question was should we reserve the
      whole free reservable space or just the window size we need.  Reserve the
      whole free reservable space will possibly force other threads which
      intended to do block allocation nearby move to another block group(cause
      bad layout).  In this patch, we just reserve the desired size before drop
      the lock and scan the block bitmap.  This patch fixed a ext3 reservation
      latency issue seen on a cvs check out test.  Patch is tested with many fsx,
      tiobench, dbench and untar a kernel test.
      Signed-Off-By: NMingming Cao <cmm@us.ibm.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      21fe3471
  14. 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