1. 27 3月, 2006 3 次提交
    • M
      [PATCH] ext3_get_blocks: multiple block allocation · b47b2478
      Mingming Cao 提交于
      Add support for multiple block allocation in ext3-get-blocks().
      
      Look up the disk block mapping and count the total number of blocks to
      allocate, then pass it to ext3_new_block(), where the real block allocation is
      performed.  Once multiple blocks are allocated, prepare the branch with those
      just allocated blocks info and finally splice the whole branch into the block
      mapping tree.
      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>
      b47b2478
    • M
      [PATCH] ext3_get_blocks: Mapping multiple blocks at a once · 89747d36
      Mingming Cao 提交于
      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:
      http://marc.theaimsgroup.com/?l=ext2-devel&m=112162230003522&w=2
      
      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
      time.
      
      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: NMingming Cao <cmm@us.ibm.com>
      Cc: Badari Pulavarty <pbadari@us.ibm.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      89747d36
    • N
      [PATCH] Make address_space_operations->invalidatepage return void · 2ff28e22
      NeilBrown 提交于
      The return value of this function is never used, so let's be honest and
      declare it as void.
      
      Some places where invalidatepage returned 0, I have inserted comments
      suggesting a BUG_ON.
      
      [akpm@osdl.org: JBD BUG fix]
      [akpm@osdl.org: rework for git-nfs]
      [akpm@osdl.org: don't go BUG in block_invalidate_page()]
      Signed-off-by: NNeil Brown <neilb@suse.de>
      Acked-by: NDave Kleikamp <shaggy@austin.ibm.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      2ff28e22
  2. 26 3月, 2006 1 次提交
  3. 24 3月, 2006 4 次提交
    • G
      [PATCH] ext3: Properly report backup block present in a group · b5a7c4f5
      Glauber de Oliveira Costa 提交于
      In filesystems with the meta block group flag on, ext3_bg_num_gdb() fails
      to report the correct number of blocks used to store the group descriptor
      backups in a given group.  It happens because meta_bg follows a different
      logic from the original ext3 backup placement in groups multiples of 3, 5
      and 7.
      Signed-off-by: NGlauber de Oliveira Costa <glommer@br.ibm.com>
      Cc: Andreas Dilger <adilger@clusterfs.com>
      Cc: "Stephen C. Tweedie" <sct@redhat.com>
      Cc: Alex Tomas <alex@clusterfs.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      b5a7c4f5
    • A
      [PATCH] fast ext3_statfs · 09fe316a
      Alex Tomas 提交于
      Under I/O load it may take up to a dozen seconds to read all group
      descriptors.  This is what ext3_statfs() does.  At the same time, we already
      maintain global numbers of free inodes/blocks.  Why don't we use them instead
      of group reading and summing?
      
      Cc: Ravikiran G Thirumalai <kiran@scalex86.org>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      09fe316a
    • P
      [PATCH] cpuset memory spread: slab cache format · fffb60f9
      Paul Jackson 提交于
      Rewrap the overly long source code lines resulting from the previous
      patch's addition of the slab cache flag SLAB_MEM_SPREAD.  This patch
      contains only formatting changes, and no function change.
      Signed-off-by: NPaul Jackson <pj@sgi.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      fffb60f9
    • P
      [PATCH] cpuset memory spread: slab cache filesystems · 4b6a9316
      Paul Jackson 提交于
      Mark file system inode and similar slab caches subject to SLAB_MEM_SPREAD
      memory spreading.
      
      If a slab cache is marked SLAB_MEM_SPREAD, then anytime that a task that's
      in a cpuset with the 'memory_spread_slab' option enabled goes to allocate
      from such a slab cache, the allocations are spread evenly over all the
      memory nodes (task->mems_allowed) allowed to that task, instead of favoring
      allocation on the node local to the current cpu.
      
      The following inode and similar caches are marked SLAB_MEM_SPREAD:
      
          file                               cache
          ====                               =====
          fs/adfs/super.c                    adfs_inode_cache
          fs/affs/super.c                    affs_inode_cache
          fs/befs/linuxvfs.c                 befs_inode_cache
          fs/bfs/inode.c                     bfs_inode_cache
          fs/block_dev.c                     bdev_cache
          fs/cifs/cifsfs.c                   cifs_inode_cache
          fs/coda/inode.c                    coda_inode_cache
          fs/dquot.c                         dquot
          fs/efs/super.c                     efs_inode_cache
          fs/ext2/super.c                    ext2_inode_cache
          fs/ext2/xattr.c (fs/mbcache.c)     ext2_xattr
          fs/ext3/super.c                    ext3_inode_cache
          fs/ext3/xattr.c (fs/mbcache.c)     ext3_xattr
          fs/fat/cache.c                     fat_cache
          fs/fat/inode.c                     fat_inode_cache
          fs/freevxfs/vxfs_super.c           vxfs_inode
          fs/hpfs/super.c                    hpfs_inode_cache
          fs/isofs/inode.c                   isofs_inode_cache
          fs/jffs/inode-v23.c                jffs_fm
          fs/jffs2/super.c                   jffs2_i
          fs/jfs/super.c                     jfs_ip
          fs/minix/inode.c                   minix_inode_cache
          fs/ncpfs/inode.c                   ncp_inode_cache
          fs/nfs/direct.c                    nfs_direct_cache
          fs/nfs/inode.c                     nfs_inode_cache
          fs/ntfs/super.c                    ntfs_big_inode_cache_name
          fs/ntfs/super.c                    ntfs_inode_cache
          fs/ocfs2/dlm/dlmfs.c               dlmfs_inode_cache
          fs/ocfs2/super.c                   ocfs2_inode_cache
          fs/proc/inode.c                    proc_inode_cache
          fs/qnx4/inode.c                    qnx4_inode_cache
          fs/reiserfs/super.c                reiser_inode_cache
          fs/romfs/inode.c                   romfs_inode_cache
          fs/smbfs/inode.c                   smb_inode_cache
          fs/sysv/inode.c                    sysv_inode_cache
          fs/udf/super.c                     udf_inode_cache
          fs/ufs/super.c                     ufs_inode_cache
          net/socket.c                       sock_inode_cache
          net/sunrpc/rpc_pipe.c              rpc_inode_cache
      
      The choice of which slab caches to so mark was quite simple.  I marked
      those already marked SLAB_RECLAIM_ACCOUNT, except for fs/xfs, dentry_cache,
      inode_cache, and buffer_head, which were marked in a previous patch.  Even
      though SLAB_RECLAIM_ACCOUNT is for a different purpose, it marks the same
      potentially large file system i/o related slab caches as we need for memory
      spreading.
      
      Given that the rule now becomes "wherever you would have used a
      SLAB_RECLAIM_ACCOUNT slab cache flag before (usually the inode cache), use
      the SLAB_MEM_SPREAD flag too", this should be easy enough to maintain.
      Future file system writers will just copy one of the existing file system
      slab cache setups and tend to get it right without thinking.
      Signed-off-by: NPaul Jackson <pj@sgi.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      4b6a9316
  4. 23 3月, 2006 3 次提交
  5. 12 3月, 2006 2 次提交
  6. 04 2月, 2006 1 次提交
  7. 02 2月, 2006 1 次提交
  8. 15 1月, 2006 1 次提交
  9. 12 1月, 2006 1 次提交
  10. 11 1月, 2006 2 次提交
  11. 10 1月, 2006 2 次提交
  12. 09 1月, 2006 3 次提交
  13. 29 11月, 2005 1 次提交
  14. 14 11月, 2005 1 次提交
  15. 09 11月, 2005 1 次提交
  16. 31 10月, 2005 3 次提交
    • G
      [PATCH] Test for sb_getblk return value · 2973dfdb
      Glauber de Oliveira Costa 提交于
      This patch adds tests for the return value of sb_getblk() in the ext2/3
      filesystems.  In fs/buffer.c it is stated that the getblk() function never
      fails.  However, it does can return NULL in some situations due to I/O
      errors, which may lead us to NULL pointer dereferences
      Signed-off-by: NGlauber de Oliveira Costa <glommer@br.ibm.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      2973dfdb
    • 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
  17. 29 10月, 2005 1 次提交
  18. 28 10月, 2005 1 次提交
    • A
      [PATCH] gfp_t: fs/* · 27496a8c
      Al Viro 提交于
       - ->releasepage() annotated (s/int/gfp_t), instances updated
       - missing gfp_t in fs/* added
       - fixed misannotation from the original sweep caught by bitwise checks:
         XFS used __nocast both for gfp_t and for flags used by XFS allocator.
         The latter left with unsigned int __nocast; we might want to add a
         different type for those but for now let's leave them alone.  That,
         BTW, is a case when __nocast use had been actively confusing - it had
         been used in the same code for two different and similar types, with
         no way to catch misuses.  Switch of gfp_t to bitwise had caught that
         immediately...
      
      One tricky bit is left alone to be dealt with later - mapping->flags is
      a mix of gfp_t and error indications.  Left alone for now.
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      27496a8c
  19. 28 9月, 2005 1 次提交
  20. 23 9月, 2005 2 次提交
  21. 10 9月, 2005 2 次提交
  22. 08 9月, 2005 1 次提交
    • M
      [PATCH] disk quotas fail when /etc/mtab is symlinked to /proc/mounts · 8fc2751b
      Mark Bellon 提交于
      If /etc/mtab is a regular file all of the mount options (of a file system)
      are written to /etc/mtab by the mount command.  The quota tools look there
      for the quota strings for their operation.  If, however, /etc/mtab is a
      symlink to /proc/mounts (a "good thing" in some environments) the tools
      don't write anything - they assume the kernel will take care of things.
      
      While the quota options are sent down to the kernel via the mount system
      call and the file system codes handle them properly unfortunately there is
      no code to echo the quota strings into /proc/mounts and the quota tools
      fail in the symlink case.
      
      The attached patchs modify the EXT[2|3] and JFS codes to add the necessary
      hooks.  The show_options function of each file system in these patches
      currently deal with only those things that seemed related to quotas;
      especially in the EXT3 case more can be done (later?).
      
      Jan Kara also noted the difficulty in moving these changes above the FS
      codes responding similarly to myself to Andrew's comment about possible
      VFS migration. Issue summary:
      
       - FS codes have to process the entire string of options anyway.
      
       - Only FS codes that use quotas must have a show_options function (for
         quotas to work properly) however quotas are only used in a small number
         of FS.
      
       - Since most of the quota using FS support other options these FS codes
         should have the a show_options function to show those options - and the
         quota echoing becomes virtually negligible.
      
      Based on feedback I have modified my patches from the original:
      
         JFS a missing patch has been restored to the posting
         EXT[2|3] and JFS always use the show_options function
             - Each FS has at least one FS specific option displayed
             - QUOTA output is under a CONFIG_QUOTA ifdef
             - a follow-on patch will add a multitude of options for each FS
         EXT[2|3] and JFS "quota" is treated as "usrquota"
         EXT3 journalled data check for journalled quota removed
         EXT[2|3] mount when quota specified but not compiled in
      
       - no changes from my original patch.  I tested the patch and the codes
         warn but
      
       - still mount.  With all due respection I believe the comments
         otherwise were a
      
       - misread of the patch.  Please reread/test and comment.  XFS patch
         removed - the XFS team already made the necessary changes EXT3 mixing
         old and new quotas are handled differently (not purely exclusive)
      
       - if old and new quotas for the same type are used together the old
         type is silently depricated for compatability (e.g.  usrquota and
         usrjquota)
      
       - mixing of old and new quotas is an error (e.g.  usrjquota and
         grpquota)
      Signed-off-by: NMark Bellon <mbellon@mvista.com>
      Acked-by: NDave Kleikamp <shaggy@austin.ibm.com>
      Cc: Jan Kara <jack@ucw.cz>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      8fc2751b
  23. 20 8月, 2005 1 次提交
    • L
      Fix nasty ncpfs symlink handling bug. · cc314eef
      Linus Torvalds 提交于
      This bug could cause oopses and page state corruption, because ncpfs
      used the generic page-cache symlink handlign functions.  But those
      functions only work if the page cache is guaranteed to be "stable", ie a
      page that was installed when the symlink walk was started has to still
      be installed in the page cache at the end of the walk.
      
      We could have fixed ncpfs to not use the generic helper routines, but it
      is in many ways much cleaner to instead improve on the symlink walking
      helper routines so that they don't require that absolute stability.
      
      We do this by allowing "follow_link()" to return a error-pointer as a
      cookie, which is fed back to the cleanup "put_link()" routine.  This
      also simplifies NFS symlink handling.
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      cc314eef
  24. 28 7月, 2005 1 次提交