[XFS updates] XFS development tree branch, xfs-quota-eofblocks-scan, created. xfs-for-linus-3.16-rc1-13111-gf074051

[xfs at oss.sgi.com]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "XFS development tree".

The branch, xfs-quota-eofblocks-scan has been created
        at  f074051ff550f9f1f1a8ab4868277d049a7fd7aa (commit)

- Log -----------------------------------------------------------------
commit f074051ff550f9f1f1a8ab4868277d049a7fd7aa
Author: Brian Foster <bfoster at redhat.com>
Date:   Thu Jul 24 19:56:08 2014 +1000

    xfs: squash prealloc while over quota free space as well
    
    From: Brian Foster <bfoster at redhat.com>
    
    Commit 4d559a3b introduced heavy prealloc. squashing to catch the case
    of requesting too large a prealloc on smaller filesystems, leading to
    repeated flush and retry cycles that occur on ENOSPC. Now that we issue
    eofblocks scans on EDQUOT/ENOSPC, squash the prealloc against the
    minimum available free space across all applicable quotas as well to
    avoid a similar problem of repeated eofblocks scans.
    
    Signed-off-by: Brian Foster <bfoster at redhat.com>
    Reviewed-by: Dave Chinner <dchinner at redhat.com>
    Signed-off-by: Dave Chinner <david at fromorbit.com>

commit dc06f398f00059707236d456d954a3a9d2a829db
Author: Brian Foster <bfoster at redhat.com>
Date:   Thu Jul 24 19:49:28 2014 +1000

    xfs: run an eofblocks scan on ENOSPC/EDQUOT
    
    From: Brian Foster <bfoster at redhat.com>
    
    Speculative preallocation and and the associated throttling metrics
    assume we're working with large files on large filesystems. Users have
    reported inefficiencies in these mechanisms when we happen to be dealing
    with large files on smaller filesystems. This can occur because while
    prealloc throttling is aggressive under low free space conditions, it is
    not active until we reach 5% free space or less.
    
    For example, a 40GB filesystem has enough space for several files large
    enough to have multi-GB preallocations at any given time. If those files
    are slow growing, they might reserve preallocation for long periods of
    time as well as avoid the background scanner due to frequent
    modification. If a new file is written under these conditions, said file
    has no access to this already reserved space and premature ENOSPC is
    imminent.
    
    To handle this scenario, modify the buffered write ENOSPC handling and
    retry sequence to invoke an eofblocks scan. In the smaller filesystem
    scenario, the eofblocks scan resets the usage of preallocation such that
    when the 5% free space threshold is met, throttling effectively takes
    over to provide fair and efficient preallocation until legitimate
    ENOSPC.
    
    The eofblocks scan is selective based on the nature of the failure. For
    example, an EDQUOT failure in a particular quota will use a filtered
    scan for that quota. Because we don't know which quota might have caused
    an allocation failure at any given time, we include each applicable
    quota determined to be under low free space conditions in the scan.
    
    Signed-off-by: Brian Foster <bfoster at redhat.com>
    Reviewed-by: Dave Chinner <dchinner at redhat.com>
    Signed-off-by: Dave Chinner <david at fromorbit.com>

commit f4526397928fff052f795713748f376a2bba1b5e
Author: Brian Foster <bfoster at redhat.com>
Date:   Thu Jul 24 19:44:28 2014 +1000

    xfs: support a union-based filter for eofblocks scans
    
    From: Brian Foster <bfoster at redhat.com>
    
    The eofblocks scan inode filter uses intersection logic by default.
    E.g., specifying both user and group quota ids filters out inodes that
    are not covered by both the specified user and group quotas. This is
    suitable for behavior exposed to userspace.
    
    Scans that are initiated from within the kernel might require more broad
    semantics, such as scanning all inodes under each quota associated with
    an inode to alleviate low free space conditions in each.
    
    Create the XFS_EOF_FLAGS_UNION flag to support a conditional union-based
    filtering algorithm for eofblocks scans. This flag is intentionally left
    out of the valid mask as it is not supported for scans initiated from
    userspace.
    
    Signed-off-by: Brian Foster <bfoster at redhat.com>
    Reviewed-by: Dave Chinner <dchinner at redhat.com>
    Signed-off-by: Dave Chinner <david at fromorbit.com>

commit 5400da7dc0862d73523691038c044535f518a57f
Author: Brian Foster <bfoster at redhat.com>
Date:   Thu Jul 24 19:40:22 2014 +1000

    xfs: add scan owner field to xfs_eofblocks
    
    From: Brian Foster <bfoster at redhat.com>
    
    The scan owner field represents an optional inode number that is
    responsible for the current scan. The purpose is to identify that an
    inode is under iolock and as such, the iolock shouldn't be attempted
    when trimming eofblocks. This is an internal only field.
    
    Signed-off-by: Brian Foster <bfoster at redhat.com>
    Reviewed-by: Dave Chinner <dchinner at redhat.com>
    Signed-off-by: Dave Chinner <david at fromorbit.com>

-----------------------------------------------------------------------


hooks/post-receive
-- 
XFS development tree