This project is mirrored from https://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-rt-devel.git. Pull mirroring updated .
  1. 05 Jan, 2012 1 commit
  2. 21 Nov, 2011 1 commit
  3. 09 Sep, 2011 11 commits
  4. 28 Jun, 2011 1 commit
  5. 25 May, 2011 1 commit
    • Allison Henderson's avatar
      ext4: add flag to ext4_has_free_blocks · 55f020db
      Allison Henderson authored
      
      
      This patch adds an allocation request flag to the ext4_has_free_blocks
      function which enables the use of reserved blocks.  This will allow a
      punch hole to proceed even if the disk is full.  Punching a hole may
      require additional blocks to first split the extents.
      
      Because ext4_has_free_blocks is a low level function, the flag needs
      to be passed down through several functions listed below:
      
      ext4_ext_insert_extent
      ext4_ext_create_new_leaf
      ext4_ext_grow_indepth
      ext4_ext_split
      ext4_ext_new_meta_block
      ext4_mb_new_blocks
      ext4_claim_free_blocks
      ext4_has_free_blocks
      
      [ext4 punch hole patch series 1/5 v7]
      
      Signed-off-by: default avatarAllison Henderson <achender@us.ibm.com>
      Signed-off-by: default avatar"Theodore Ts'o" <tytso@mit.edu>
      Reviewed-by: default avatarMingming Cao <cmm@us.ibm.com>
      55f020db
  6. 09 May, 2011 1 commit
  7. 01 May, 2011 1 commit
  8. 31 Mar, 2011 1 commit
  9. 22 Mar, 2011 1 commit
  10. 10 Jan, 2011 1 commit
  11. 28 Oct, 2010 2 commits
  12. 12 Jun, 2010 1 commit
    • Theodore Ts'o's avatar
      ext4: Clean up s_dirt handling · a0375156
      Theodore Ts'o authored
      
      
      We don't need to set s_dirt in most of the ext4 code when journaling
      is enabled.  In ext3/4 some of the summary statistics for # of free
      inodes, blocks, and directories are calculated from the per-block
      group statistics when the file system is mounted or unmounted.  As a
      result the superblock doesn't have to be updated, either via the
      journal or by setting s_dirt.  There are a few exceptions, most
      notably when resizing the file system, where the superblock needs to
      be modified --- and in that case it should be done as a journalled
      operation if possible, and s_dirt set only in no-journal mode.
      
      This patch will optimize out some unneeded disk writes when using ext4
      with a journal.
      
      Signed-off-by: default avatar"Theodore Ts'o" <tytso@mit.edu>
      a0375156
  13. 16 May, 2010 1 commit
    • Eric Sandeen's avatar
      ext4: don't use quota reservation for speculative metadata · 72b8ab9d
      Eric Sandeen authored
      
      
      Because we can badly over-reserve metadata when we
      calculate worst-case, it complicates things for quota, since
      we must reserve and then claim later, retry on EDQUOT, etc.
      Quota is also a generally smaller pool than fs free blocks,
      so this over-reservation hurts more, and more often.
      
      I'm of the opinion that it's not the worst thing to allow
      metadata to push a user slightly over quota.  This simplifies
      the code and avoids the false quota rejections that result
      from worst-case speculation.
      
      This patch stops the speculative quota-charging for
      worst-case metadata requirements, and just charges quota
      when the blocks are allocated at writeout.  It also is
      able to remove the try-again loop on EDQUOT.
      
      This patch has been tested indirectly by running the xfstests
      suite with a hack to mount & enable quota prior to the test.
      
      I also did a more specific test of fragmenting freespace
      and then doing a large delalloc write under quota; quota
      stopped me at the right amount of file IO, and then the
      writeout generated enough metadata (due to the fragmentation)
      that it put me slightly over quota, as expected.
      
      Signed-off-by: default avatarEric Sandeen <sandeen@redhat.com>
      Signed-off-by: default avatar"Theodore Ts'o" <tytso@mit.edu>
      72b8ab9d
  14. 04 Mar, 2010 2 commits
  15. 15 Feb, 2010 1 commit
  16. 22 Nov, 2009 1 commit
  17. 23 Nov, 2009 1 commit
  18. 18 Aug, 2009 1 commit
    • Eric Sandeen's avatar
      ext4: open-code ext4_mb_update_group_info · 0373130d
      Eric Sandeen authored
      
      
      ext4_mb_update_group_info is only called in one place, and it's
      extremely simple.  There's no reason to have it in a separate function
      in a separate file as far as I can tell, it just obfuscates what's
      really going on.
      
      Perhaps it was intended to keep the grp->bb_* manipulation local to
      mballoc.c but we're already accessing other grp-> fields in balloc.c
      directly so this seems ok.
      
      Signed-off-by: default avatarEric Sandeen <sandeen@redhat.com>
      Signed-off-by: default avatar"Theodore Ts'o" <tytso@mit.edu>
      0373130d
  19. 03 May, 2009 1 commit
  20. 01 May, 2009 2 commits
    • Theodore Ts'o's avatar
      ext4: Move fs/ext4/group.h into ext4.h · bb23c20a
      Theodore Ts'o authored
      
      
      Move the function prototypes in group.h into ext4.h so they are all
      defined in one place.
      
      Signed-off-by: default avatar"Theodore Ts'o" <tytso@mit.edu>
      bb23c20a
    • Theodore Ts'o's avatar
      ext4: Avoid races caused by on-line resizing and SMP memory reordering · 8df9675f
      Theodore Ts'o authored
      
      
      Ext4's on-line resizing adds a new block group and then, only at the
      last step adjusts s_groups_count.  However, it's possible on SMP
      systems that another CPU could see the updated the s_group_count and
      not see the newly initialized data structures for the just-added block
      group.  For this reason, it's important to insert a SMP read barrier
      after reading s_groups_count and before reading any (for example) the
      new block group descriptors allowed by the increased value of
      s_groups_count.
      
      Unfortunately, we rather blatently violate this locking protocol
      documented in fs/ext4/resize.c.  Fortunately, (1) on-line resizes
      happen relatively rarely, and (2) it seems rare that the filesystem
      code will immediately try to use just-added block group before any
      memory ordering issues resolve themselves.  So apparently problems
      here are relatively hard to hit, since ext3 has been vulnerable to the
      same issue for years with no one apparently complaining.
      
      Signed-off-by: default avatar"Theodore Ts'o" <tytso@mit.edu>
      8df9675f
  21. 26 Mar, 2009 1 commit
  22. 05 Mar, 2009 1 commit
  23. 26 Feb, 2009 1 commit
  24. 06 Feb, 2009 1 commit
  25. 27 Jan, 2009 1 commit
  26. 06 Jan, 2009 1 commit
  27. 04 Jan, 2009 1 commit