18 Dec, 2012

1 commit


15 May, 2012

1 commit

  • xfs_trans_ail_delete_bulk() can be called from different contexts so
    if the item is not in the AIL we need different shutdown for each
    context. Pass in the shutdown method needed so the correct action
    can be taken.

    Signed-off-by: Dave Chinner
    Reviewed-by: Christoph Hellwig
    Reviewed-by: Mark Tinguely
    Signed-off-by: Ben Myers

    Dave Chinner
     

14 Mar, 2012

3 commits

  • Add an in-memory only flag to say we logged timestamps only, and use it to
    check if fdatasync can optimize away the log force.

    Reviewed-by: Dave Chinner
    Signed-off-by: Christoph Hellwig
    Reviewed-by: Mark Tinguely
    Signed-off-by: Ben Myers

    Christoph Hellwig
     
  • Add a new ili_fields member to the inode log item to isolate the in-memory
    flags from the ones that actually go to the log. This will allow tracking
    timestamp-only updates for fdatasync and O_DSYNC in the next patch and
    prepares for divorcing the on-disk log format from the in-memory log item
    a little further down the road.

    Reviewed-by: Dave Chinner
    Signed-off-by: Christoph Hellwig
    Reviewed-by: Mark Tinguely
    Signed-off-by: Ben Myers

    Christoph Hellwig
     
  • Timestamps on regular files are the last metadata that XFS does not update
    transactionally. Now that we use the delaylog mode exclusively and made
    the log scode scale extremly well there is no need to bypass that code for
    timestamp updates. Logging all updates allows to drop a lot of code, and
    will allow for further performance improvements later on.

    Note that this patch drops optimized handling of fdatasync - it will be
    added back in a separate commit.

    Reviewed-by: Dave Chinner
    Signed-off-by: Christoph Hellwig
    Reviewed-by: Mark Tinguely
    Signed-off-by: Ben Myers

    Christoph Hellwig
     

27 Jul, 2010

2 commits

  • Currently we need to either call IHOLD or xfs_trans_ihold on an inode when
    joining it to a transaction via xfs_trans_ijoin.

    This patches instead makes xfs_trans_ijoin usable on it's own by doing
    an implicity xfs_trans_ihold, which also allows us to drop the third
    argument. For the case where we want to hold a reference on the inode
    a xfs_trans_ijoin_ref wrapper is added which does the IHOLD and marks
    the inode for needing an xfs_iput. In addition to the cleaner interface
    to the caller this also simplifies the implementation.

    Signed-off-by: Christoph Hellwig
    Reviewed-by: Dave Chinner

    Christoph Hellwig
     
  • Stop the function pointer casting madness and give all the li_cb instances
    correct prototype.

    Signed-off-by: Christoph Hellwig
    Reviewed-by: Dave Chinner

    Christoph Hellwig
     

02 Feb, 2010

1 commit

  • All buffers logged into the AIL are marked as delayed write.
    When the AIL needs to push the buffer out, it issues an async write of the
    buffer. This means that IO patterns are dependent on the order of
    buffers in the AIL.

    Instead of flushing the buffer, promote the buffer in the delayed
    write list so that the next time the xfsbufd is run the buffer will
    be flushed by the xfsbufd. Return the state to the xfsaild that the
    buffer was promoted so that the xfsaild knows that it needs to cause
    the xfsbufd to run to flush the buffers that were promoted.

    Using the xfsbufd for issuing the IO allows us to dispatch all
    buffer IO from the one queue. This means that we can make much more
    enlightened decisions on what order to flush buffers to disk as
    we don't have multiple places issuing IO. Optimisations to xfsbufd
    will be in a future patch.

    Version 2
    - kill XFS_ITEM_FLUSHING as it is now unused.

    Signed-off-by: Dave Chinner
    Reviewed-by: Christoph Hellwig

    Dave Chinner
     

17 Dec, 2009

1 commit

  • For a long time we've always stored bmap btree records in the 64bit format,
    so kill off the dead 32bit type, and make sure the 64bit type is named just
    xfs_bmbt_rec everywhere, without any size postfix.

    Signed-off-by: Christoph Hellwig
    Reviewed-by: Eric Sandeen
    Signed-off-by: Alex Elder

    Christoph Hellwig
     

02 Sep, 2009

1 commit

  • xfs_trans_iget is a wrapper for xfs_iget that adds the inode to the
    transaction after it is read. Except when the inode already is in the
    inode cache, in which case it returns the existing locked inode with
    increment lock recursion counts.

    Now, no one in the tree every decrements these lock recursion counts,
    so any user of this gets a potential double unlock when both the original
    owner of the inode and the xfs_trans_iget caller unlock it. When looking
    back in a git bisect in the historic XFS tree there was only one place
    that decremented these counts, xfs_trans_iput. Introduced in commit
    ca25df7a840f426eb566d52667b6950b92bb84b5 by Adam Sweeney in 1993,
    and removed in commit 19f899a3ab155ff6a49c0c79b06f2f61059afaf3 by
    Steve Lord in 2003. And as long as it didn't slip through git bisects
    cracks never actually used in that time frame.

    A quick audit of the callers of xfs_trans_iget shows that no caller
    really relies on this behaviour fortunately - xfs_ialloc allows this
    inode from disk so it must not be there before, and all the RT allocator
    routines only every add each RT bitmap inode once.

    In addition to removing lots of code and reducing the size of the inode
    item this patch also avoids the double inode cache lookup in each
    create/mkdir/mknod transaction.

    Signed-off-by: Christoph Hellwig
    Reviewed-by: Alex Elder
    Signed-off-by: Felix Blyakher

    Christoph Hellwig
     

22 Jan, 2009

1 commit


16 Jan, 2009

1 commit


30 Oct, 2008

1 commit


18 Apr, 2008

1 commit


28 Sep, 2006

1 commit


09 Jun, 2006

1 commit


02 Nov, 2005

2 commits


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