29 Mar, 2009

1 commit


30 Oct, 2008

6 commits

  • Under heavy metadata load we are seeing log hangs. The AIL has items in it
    ready to be pushed, and they are within the push target window. However,
    we are not pushing them when the last pushed LSN is less than the LSN of
    the first log item on the AIL. This is a regression introduced by the AIL
    push cursor modifications.

    SGI-PV: 987246

    SGI-Modid: xfs-linux-melb:xfs-kern:32409a

    Signed-off-by: David Chinner
    Signed-off-by: Lachlan McIlroy
    Signed-off-by: Tim Shimmin

    David Chinner
     
  • Change all the remaining AIL API functions that are passed struct
    xfs_mount pointers to pass pointers directly to the struct xfs_ail being
    used. With this conversion, all external access to the AIL is via the
    struct xfs_ail. Hence the operation and referencing of the AIL is almost
    entirely independent of the xfs_mount that is using it - it is now much
    more tightly tied to the log and the items it is tracking in the log than
    it is tied to the xfs_mount.

    SGI-PV: 988143

    SGI-Modid: xfs-linux-melb:xfs-kern:32353a

    Signed-off-by: David Chinner
    Signed-off-by: Lachlan McIlroy
    Signed-off-by: Christoph Hellwig

    David Chinner
     
  • Bring the ail lock inside the struct xfs_ail. This means the AIL can be
    entirely manipulated via the struct xfs_ail rather than needing both the
    struct xfs_mount and the struct xfs_ail.

    SGI-PV: 988143

    SGI-Modid: xfs-linux-melb:xfs-kern:32350a

    Signed-off-by: David Chinner
    Signed-off-by: Lachlan McIlroy
    Signed-off-by: Christoph Hellwig

    David Chinner
     
  • With the new cursor interface, it makes sense to make all the traversing
    code use the cursor interface and make the old one go away. This means
    more of the AIL interfacing is done by passing struct xfs_ail pointers
    around the place instead of struct xfs_mount pointers.

    We can replace the use of xfs_trans_first_ail() in xfs_log_need_covered()
    as it is only checking if the AIL is empty. We can do that with a call to
    xfs_trans_ail_tail() instead, where a zero LSN returned indicates and
    empty AIL...

    SGI-PV: 988143

    SGI-Modid: xfs-linux-melb:xfs-kern:32348a

    Signed-off-by: David Chinner
    Signed-off-by: Lachlan McIlroy
    Signed-off-by: Christoph Hellwig

    David Chinner
     
  • To replace the current generation number ensuring sanity of the AIL
    traversal, replace it with an external cursor that is linked to the AIL.

    Basically, we store the next item in the cursor whenever we want to drop
    the AIL lock to do something to the current item. When we regain the lock.
    the current item may already be free, so we can't reference it, but the
    next item in the traversal is already held in the cursor.

    When we move or delete an object, we search all the active cursors and if
    there is an item match we clear the cursor(s) that point to the object.
    This forces the traversal to restart transparently.

    We don't invalidate the cursor on insert because the cursor still points
    to a valid item. If the intem is inserted between the current item and the
    cursor it does not matter; the traversal is considered to be past the
    insertion point so it will be picked up in the next traversal.

    Hence traversal restarts pretty much disappear altogether with this method
    of traversal, which should substantially reduce the overhead of pushing on
    a busy AIL.

    Version 2 o add restart logic o comment cursor interface o minor cleanups

    SGI-PV: 988143

    SGI-Modid: xfs-linux-melb:xfs-kern:32347a

    Signed-off-by: David Chinner
    Signed-off-by: Lachlan McIlroy
    Signed-off-by: Christoph Hellwig

    David Chinner
     
  • Rather than embedding the struct xfs_ail in the struct xfs_mount, allocate
    it during AIL initialisation. Add a back pointer to the struct xfs_ail so
    that we can pass around the xfs_ail and still be able to access the
    xfs_mount if need be. This is th first step involved in isolating the AIL
    implementation from the surrounding filesystem code.

    SGI-PV: 988143

    SGI-Modid: xfs-linux-melb:xfs-kern:32346a

    Signed-off-by: David Chinner
    Signed-off-by: Lachlan McIlroy
    Signed-off-by: Christoph Hellwig

    David Chinner
     

18 Apr, 2008

2 commits


06 Mar, 2008

1 commit

  • wakeups

    Idle state is not being detected properly by the xfsaild push code. The
    current idle state is detected by an empty list which may never happen
    with mostly idle filesystem or one using lazy superblock counters. A
    single dirty item in the list that exists beyond the push target can
    result repeated looping attempting to push up to the target because it
    fails to check if the push target has been acheived or not.

    Fix by considering a dirty list with everything past the target as an idle
    state and set the timeout appropriately.

    SGI-PV: 977545
    SGI-Modid: xfs-linux-melb:xfs-kern:30532a

    Signed-off-by: David Chinner
    Signed-off-by: Christoph Hellwig
    Signed-off-by: Lachlan McIlroy

    David Chinner
     

07 Feb, 2008

3 commits

  • Checking the entire AIL on every insert and remove is prohibitively
    expensive - the sustained sequntial create rate on a single disk drops
    from about 1800/s to 60/s because of this checking resulting in the
    xfslogd becoming cpu bound.

    By default on debug builds, only check the next and previous entries in
    the list to ensure they are ordered correctly. If you really want, define
    XFS_TRANS_DEBUG to use the old behaviour.

    SGI-PV: 972759
    SGI-Modid: xfs-linux-melb:xfs-kern:30372a

    Signed-off-by: David Chinner
    Signed-off-by: Lachlan McIlroy

    David Chinner
     
  • When many hundreds to thousands of threads all try to do simultaneous
    transactions and the log is in a tail-pushing situation (i.e. full), we
    can get multiple threads walking the AIL list and contending on the AIL
    lock.

    The AIL push is, in effect, a simple I/O dispatch algorithm complicated by
    the ordering constraints placed on it by the transaction subsystem. It
    really does not need multiple threads to push on it - even when only a
    single CPU is pushing the AIL, it can push the I/O out far faster that
    pretty much any disk subsystem can handle.

    So, to avoid contention problems stemming from multiple list walkers, move
    the list walk off into another thread and simply provide a "target" to
    push to. When a thread requires a push, it sets the target and wakes the
    push thread, then goes to sleep waiting for the required amount of space
    to become available in the log.

    This mechanism should also be a lot fairer under heavy load as the waiters
    will queue in arrival order, rather than queuing in "who completed a push
    first" order.

    Also, by moving the pushing to a separate thread we can do more
    effectively overload detection and prevention as we can keep context from
    loop iteration to loop iteration. That is, we can push only part of the
    list each loop and not have to loop back to the start of the list every
    time we run. This should also help by reducing the number of items we try
    to lock and/or push items that we cannot move.

    Note that this patch is not intended to solve the inefficiencies in the
    AIL structure and the associated issues with extremely large list
    contents. That needs to be addresses separately; parallel access would
    cause problems to any new structure as well, so I'm only aiming to isolate
    the structure from unbounded parallelism here.

    SGI-PV: 972759
    SGI-Modid: xfs-linux-melb:xfs-kern:30371a

    Signed-off-by: David Chinner
    Signed-off-by: Lachlan McIlroy

    David Chinner
     
  • SGI-PV: 970382
    SGI-Modid: xfs-linux-melb:xfs-kern:29739a

    Signed-off-by: Donald Douwsma
    Signed-off-by: Eric Sandeen
    Signed-off-by: Tim Shimmin

    Donald Douwsma
     

15 Oct, 2007

1 commit

  • One of the perpetual scaling problems XFS has is indexing it's incore
    inodes. We currently uses hashes and the default hash sizes chosen can
    only ever be a tradeoff between memory consumption and the maximum
    realistic size of the cache.

    As a result, anyone who has millions of inodes cached on a filesystem
    needs to tunes the size of the cache via the ihashsize mount option to
    allow decent scalability with inode cache operations.

    A further problem is the separate inode cluster hash, whose size is based
    on the ihashsize but is smaller, and so under certain conditions (sparse
    cluster cache population) this can become a limitation long before the
    inode hash is causing issues.

    The following patchset removes the inode hash and cluster hash and
    replaces them with radix trees to avoid the scalability limitations of the
    hashes. It also reduces the size of the inodes by 3 pointers....

    SGI-PV: 969561
    SGI-Modid: xfs-linux-melb:xfs-kern:29481a

    Signed-off-by: David Chinner
    Signed-off-by: Christoph Hellwig
    Signed-off-by: Tim Shimmin

    David Chinner
     

10 Feb, 2007

1 commit


28 Sep, 2006

1 commit

  • xfs_trans_delete_ail

    xfs_trans_update_ail and xfs_trans_delete_ail get called with the AIL lock
    held, and release it. Add lock annotations to these two functions so that
    sparse can check callers for lock pairing, and so that sparse will not
    complain about these functions since they intentionally use locks in this
    manner.

    SGI-PV: 954580
    SGI-Modid: xfs-linux-melb:xfs-kern:26807a

    Signed-off-by: Josh Triplett
    Signed-off-by: Nathan Scott
    Signed-off-by: Tim Shimmin

    Josh Triplett
     

20 Jun, 2006

1 commit


09 Jun, 2006

1 commit


02 Nov, 2005

2 commits


02 Sep, 2005

1 commit


17 Apr, 2005

1 commit

  • 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!

    Linus Torvalds