Skip to content

L
linux
Switch branch/tag
  1. 30 Jul, 2009 5 commits
    • Benjamin Marzinski's avatar
      GFS2: Don't put unlikely reclaim candidates on the reclaim list. · 8ff22a6f
      Benjamin Marzinski authored 
      GFS2 was placing far too many glocks on the reclaim list that were not good
candidates for freeing up from cache.  These locks would sit there and
repeatedly get scanned to see if they could be reclaimed, wasting a lot
of time when there was memory pressure. This fix does more checks on the
locks to see if they are actually likely to be removable from cache.
Signed-off-by: default avatarBenjamin Marzinski <bmarzins@redhat.com>
Signed-off-by: default avatarSteven Whitehouse <swhiteho@redhat.com>
      8ff22a6f
    • Steven Whitehouse's avatar
      GFS2: Don't try and dealloc own inode · 1e19a195
      Steven Whitehouse authored 
      When searching for unlinked, but still allocated inodes during block
allocation, avoid the block relating to the inode that is doing the
allocation. This fixes a hang caused when an unlinked, but still
open, inode tries to allocate some more blocks and lands up
finding itself during the search for deallocatable inodes.
Signed-off-by: default avatarSteven Whitehouse <swhiteho@redhat.com>
      1e19a195
    • Benjamin Marzinski's avatar
      GFS2: Fix panic in glock memory shrinker · a51b56ff
      Benjamin Marzinski authored 
      It is possible for gfs2_shrink_glock_memory() to check a glock for
demotion
that's in the process of being freed by gfs2_glock_put().  In this case,
gfs2_shrink_glock_memory() will acquire a new reference to this glock,
and
then try to free the glock itself when it drops the refernce.  To solve
this, gfs2_shrink_glock_memory() just needs to check if the glock is in
the process of being freed, and if so skip it without ever unlocking the
lru_lock.
Signed-off-by: default avatarBenjamin Marzinski <bmarzins@redhat.com>
Acked-by: default avatarBob Peterson <rpeterso@redhat.com>
Signed-off-by: default avatarSteven Whitehouse <swhiteho@redhat.com>
      a51b56ff
    • Benjamin Marzinski's avatar
      GFS2: keep statfs info in sync on grows · 1946f70a
      Benjamin Marzinski authored 
      GFS2 wasn't syncing its statfs info on grows.  This causes a problem
when you grow the filesystem on multiple nodes.  GFS2 would calculate
the new space based on the resource groups (which are always current),
and then assume that the filesystem had grown the from the existing
statfs size.  If you grew the filesystem on two different nodes in a
short time, the second node wouldn't see the statfs size change from the
first node, and would assume that it was grown by a larger amount than
it was.  When all these changes were synced out, the total fileystem
size would be incorrect (the first grow would be counted twice).

This patch syncs makes GFS2 read in the statfs changes from disk before
a grow, and write them out after the grow, while the master statfs inode
is locked.
Signed-off-by: default avatarBenjamin Marzinski <bmarzins@redhat.com>
Signed-off-by: default avatarSteven Whitehouse <swhiteho@redhat.com>
      1946f70a
    • Steven Whitehouse's avatar
      GFS2: Shrink the shrinker · 2163b1e6
      Steven Whitehouse authored 
      This patch removes some of the special cases that the shrinker
was trying to deal with. As a result we leave fewer items on
the list and none at all which cannot be demoted. This makes
the list scanning more efficient and solves some issues seen
with large numbers of inodes.
Signed-off-by: default avatarSteven Whitehouse <swhiteho@redhat.com>
      2163b1e6
  3. 23 Jul, 2009 1 commit
  5. 22 Jul, 2009 34 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7