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, for-next has been updated
9e5987a xfs: rearrange some code in xfs_bmap for better locality
ecb3403 xfs: rename random32() to prandom_u32()
d5929de xfs: don't verify buffers after IO errors
e8108ce xfs: fix xfs_iomap_eof_prealloc_initial_size type
e114b5f xfs: increase prealloc size to double that of the previous extent
e78c420 xfs: fix potential infinite loop in xfs_iomap_prealloc_size()
from 6dbe51c251a327e012439c4772097a13df43c5b8 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -----------------------------------------------------------------
commit 9e5987a7792194ec338f53643237150c0db5f5e0
Author: Dave Chinner <dchinner@xxxxxxxxxx>
Date: Mon Feb 25 12:31:26 2013 +1100
xfs: rearrange some code in xfs_bmap for better locality
xfs_bmap.c is a big file, and some of the related code is spread all
throughout the file requiring function prototypes for static
function and jumping all through the file to follow a single call
path. Rearrange the code so that:
a) related functionality is grouped together; and
b) functions are grouped in call dependency order
While the diffstat is large, there are no code changes in the patch;
it is just moving the functionality around and removing the function
prototypes at the top of the file. The resulting layout of the code
is as follows (top of file to bottom):
- miscellaneous helper functions
- extent tree block counting routines
- debug/sanity checking code
- bmap free list manipulation functions
- inode fork format manipulation functions
- internal/external extent tree seach functions
- extent tree manipulation functions used during allocation
- functions used during extent read/allocate/removal
operations (i.e. xfs_bmapi_write, xfs_bmapi_read,
xfs_bunmapi and xfs_getbmap)
This means that following logic paths through the bmapi code is much
simpler - most of the code relevant to a specific operation is now
clustered together rather than spread all over the file....
Signed-off-by: Dave Chinner <dchinner@xxxxxxxxxx>
Reviewed-by: Mark Tinguely <tinguely@xxxxxxx>
Signed-off-by: Ben Myers <bpm@xxxxxxx>
commit ecb3403de1efb56f78d9093376aec0a8af76b316
Author: Akinobu Mita <akinobu.mita@xxxxxxxxx>
Date: Mon Mar 4 21:58:20 2013 +0900
xfs: rename random32() to prandom_u32()
Use more preferable function name which implies using a pseudo-random
number generator.
Signed-off-by: Akinobu Mita <akinobu.mita@xxxxxxxxx>
Acked-by: <bpm@xxxxxxx>
Cc: Ben Myers <bpm@xxxxxxx>
Cc: Alex Elder <elder@xxxxxxxxxx>
Cc: xfs@xxxxxxxxxxx
Signed-off-by: Ben Myers <bpm@xxxxxxx>
commit d5929de8337fef46f3e307914ed0f3cb845e66c1
Author: Dave Chinner <dchinner@xxxxxxxxxx>
Date: Wed Feb 27 13:25:54 2013 +1100
xfs: don't verify buffers after IO errors
When we read a buffer, we might get an error from the underlying
block device and not the real data. Hence if we get an IO error, we
shouldn't run the verifier but instead just pass the IO error
straight through.
Signed-off-by: Dave Chinner <dchinner@xxxxxxxxxx>
Reviewed-by: Mark Tinguely <tinguely@xxxxxxx>
Signed-off-by: Ben Myers <bpm@xxxxxxx>
commit e8108cedb1c5d1dc359690d18ca997e97a0061d2
Author: Mark Tinguely <tinguely@xxxxxxx>
Date: Sun Feb 24 13:04:37 2013 -0600
xfs: fix xfs_iomap_eof_prealloc_initial_size type
Fix the return type of xfs_iomap_eof_prealloc_initial_size() to
xfs_fsblock_t to reflect the fact that the return value may be an
unsigned 64 bits if XFS_BIG_BLKNOS is defined.
Signed-off-by: Mark Tinguely <tinguely@xxxxxxx>
Reviewed-by: Dave Chinner <dchinner@xxxxxxxxxx>
Signed-off-by: Ben Myers <bpm@xxxxxxx>
commit e114b5fce6befb8fa345d7cf1a4de8ce5a211910
Author: Brian Foster <bfoster@xxxxxxxxxx>
Date: Tue Feb 19 10:24:41 2013 -0500
xfs: increase prealloc size to double that of the previous extent
The updated speculative preallocation algorithm for handling sparse
files can becomes less effective in situations with a high number of
concurrent, sequential writers. The number of writers and amount of
available RAM affect the writeback bandwidth slicing algorithm,
which in turn affects the block allocation pattern of XFS. For
example, running 32 sequential writers on a system with 32GB RAM,
preallocs become fixed at a value of around 128MB (instead of
steadily increasing to the 8GB maximum as sequential writes
proceed).
Update the speculative prealloc heuristic to base the size of the
next prealloc on double the size of the preceding extent. This
preserves the original aggressive speculative preallocation
behavior and continues to accomodate sparse files at a slight cost
of increasing the size of preallocated data regions following holes
of sparse files.
Signed-off-by: Brian Foster <bfoster@xxxxxxxxxx>
Reviewed-by: Dave Chinner <dchinner@xxxxxxxxxx>
Signed-off-by: Ben Myers <bpm@xxxxxxx>
commit e78c420bfc2608bb5f9a0b9165b1071c1e31166a
Author: Brian Foster <bfoster@xxxxxxxxxx>
Date: Fri Feb 22 13:32:56 2013 -0500
xfs: fix potential infinite loop in xfs_iomap_prealloc_size()
If freesp == 0, we could end up in an infinite loop while squashing
the preallocation. Break the loop when we've killed the prealloc
entirely.
Signed-off-by: Brian Foster <bfoster@xxxxxxxxxx>
Reviewed-by: Dave Chinner <dchinner@xxxxxxxxxx>
Signed-off-by: Ben Myers <bpm@xxxxxxx>
-----------------------------------------------------------------------
Summary of changes:
fs/xfs/xfs_alloc.c | 2 +-
fs/xfs/xfs_bmap.c | 10659 +++++++++++++++++++++++++-------------------------
fs/xfs/xfs_buf.c | 4 +-
fs/xfs/xfs_error.c | 2 +-
fs/xfs/xfs_ialloc.c | 2 +-
fs/xfs/xfs_iomap.c | 6 +-
fs/xfs/xfs_log.c | 2 +-
7 files changed, 5271 insertions(+), 5406 deletions(-)
hooks/post-receive
--
XFS development tree
_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs
