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, master has been updated
eb54d19 Merge branch 'zero-range' of git://git.kernel.org/pub/scm/linux/kernel/git/dgc/xfsdev
cb7a934 Merge branch '2.6.36-xfs-misc' of git://git.kernel.org/pub/scm/linux/kernel/git/dgc/xfsdev
9af2546 xfs: Make fiemap work with sparse files
72656c4 xfs: prevent 32bit overflow in space reservation
23963e5 xfs: Disallow 32bit project quota id
9bc08a4 xfs: improve buffer cache hash scalability
16afe0a xfs: Introduce XFS_IOC_ZERO_RANGE
e113b44 xfs: use range primitives for xfs page cache operations
from 2bfc96a127bc1cc94d26bfaa40159966064f9c8c (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 eb54d193fdeade04351a9fa790eb1f61604950de
Merge: cb7a93412ab52361bc255cbe2c767e0741c09f43 16afe0a2a59d5e42368fcb820b72b740e670140e
Author: Alex Elder <aelder@xxxxxxx>
Date: Fri Sep 3 09:31:49 2010 -0500
Merge branch 'zero-range' of git://git.kernel.org/pub/scm/linux/kernel/git/dgc/xfsdev
commit cb7a93412ab52361bc255cbe2c767e0741c09f43
Merge: 9af25465081480a75824fd7a16a37a5cfebeede9 72656c46f50b8dfe50e15793692982e636e3df20
Author: Alex Elder <aelder@xxxxxxx>
Date: Fri Sep 3 09:02:32 2010 -0500
Merge branch '2.6.36-xfs-misc' of git://git.kernel.org/pub/scm/linux/kernel/git/dgc/xfsdev
commit 9af25465081480a75824fd7a16a37a5cfebeede9
Author: Tao Ma <tao.ma@xxxxxxxxxx>
Date: Mon Aug 30 02:44:03 2010 +0000
xfs: Make fiemap work with sparse files
In xfs_vn_fiemap, we set bvm_count to fi_extent_max + 1 and want
to return fi_extent_max extents, but actually it won't work for
a sparse file. The reason is that in xfs_getbmap we will
calculate holes and set it in 'out', while out is malloced by
bmv_count(fi_extent_max+1) which didn't consider holes. So in the
worst case, if 'out' vector looks like
[hole, extent, hole, extent, hole, ... hole, extent, hole],
we will only return half of fi_extent_max extents.
This patch add a new parameter BMV_IF_NO_HOLES for bvm_iflags.
So with this flags, we don't use our 'out' in xfs_getbmap for
a hole. The solution is a bit ugly by just don't increasing
index of 'out' vector. I felt that it is not easy to skip it
at the very beginning since we have the complicated check and
some function like xfs_getbmapx_fix_eof_hole to adjust 'out'.
Cc: Dave Chinner <david@xxxxxxxxxxxxx>
Signed-off-by: Tao Ma <tao.ma@xxxxxxxxxx>
Signed-off-by: Alex Elder <aelder@xxxxxxx>
commit 72656c46f50b8dfe50e15793692982e636e3df20
Author: Dave Chinner <dchinner@xxxxxxxxxx>
Date: Fri Sep 3 12:19:33 2010 +1000
xfs: prevent 32bit overflow in space reservation
If we attempt to preallocate more than 2^32 blocks of space in a
single syscall, the transaction block reservation will overflow
leading to a hangs in the superblock block accounting code. This
is trivially reproduced with xfs_io. Fix the problem by capping the
allocation reservation to the maximum number of blocks a single
xfs_bmapi() call can allocate (2^21 blocks).
Signed-off-by: Dave Chinner <dchinner@xxxxxxxxxx>
Reviewed-by: Christoph Hellwig <hch@xxxxxx>
commit 23963e54ce187ca6e907c83176c15508b0f6e60d
Author: Arkadiusz Mi?kiewicz <arekm@xxxxxxxx>
Date: Thu Aug 26 10:19:43 2010 +0000
xfs: Disallow 32bit project quota id
Currently on-disk structure is able to keep only 16bit project quota
id, so disallow 32bit ones. This fixes a problem where parts of
kernel structures holding project quota id are 32bit while parts
(on-disk) are 16bit variables which causes project quota member
files to be inaccessible for some operations (like mv/rm).
Signed-off-by: Arkadiusz Mi?kiewicz <arekm@xxxxxxxx>
Reviewed-by: Christoph Hellwig <hch@xxxxxx>
Signed-off-by: Alex Elder <aelder@xxxxxxx>
commit 9bc08a45fb117c696e4940cfa1208cb1cc7a2f25
Author: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Thu Sep 2 15:14:38 2010 +1000
xfs: improve buffer cache hash scalability
When doing large parallel file creates on a 16p machines, large amounts of
time is being spent in _xfs_buf_find(). A system wide profile with perf top
shows this:
1134740.00 19.3% _xfs_buf_find
733142.00 12.5% __ticket_spin_lock
The problem is that the hash contains 45,000 buffers, and the hash table width
is only 256 buffers. That means we've got around 200 buffers per chain, and
searching it is quite expensive. The hash table size needs to increase.
Secondly, every time we do a lookup, we promote the buffer we find to the head
of the hash chain. This is causing cachelines to be dirtied and causes
invalidation of cachelines across all CPUs that may have walked the hash chain
recently. hence every walk of the hash chain is effectively a cold cache walk.
Remove the promotion to avoid this invalidation.
The results are:
1045043.00 21.2% __ticket_spin_lock
326184.00 6.6% _xfs_buf_find
A 70% drop in the CPU usage when looking up buffers. Unfortunately that does
not result in an increase in performance underthis workload as contention on
the inode_lock soaks up most of the reduction in CPU usage.
Signed-off-by: Dave Chinner <dchinner@xxxxxxxxxx>
Reviewed-by: Christoph Hellwig <hch@xxxxxx>
commit 16afe0a2a59d5e42368fcb820b72b740e670140e
Author: Dave Chinner <dchinner@xxxxxxxxxx>
Date: Tue Aug 24 12:02:11 2010 +1000
xfs: Introduce XFS_IOC_ZERO_RANGE
XFS_IOC_ZERO_RANGE is the equivalent of an atomic XFS_IOC_UNRESVSP/
XFS_IOC_RESVSP call pair. It enabled ranges of written data to be
turned into zeroes without requiring IO or having to free and
reallocate the extents in the range given as would occur if we had
to punch and then preallocate them separately. This enables
applications to zero parts of files very quickly without changing
the layout of the files in any way.
Signed-off-by: Dave Chinner <dchinner@xxxxxxxxxx>
Reviewed-by: Christoph Hellwig <hch@xxxxxx>
commit e113b448a9a5387f1b2ed0ef86903f2c873b83c4
Author: Dave Chinner <dchinner@xxxxxxxxxx>
Date: Tue Aug 24 12:01:50 2010 +1000
xfs: use range primitives for xfs page cache operations
While XFS passes ranges to operate on from the core code, the
functions being called ignore the either the entire range or the end
of the range. This is historical because when the function were
written linux didn't have the necessary range operations. Update the
functions to use the correct operations.
Signed-off-by: Dave Chinner <dchinner@xxxxxxxxxx>
Reviewed-by: Christoph Hellwig <hch@xxxxxx>
-----------------------------------------------------------------------
Summary of changes:
fs/xfs/linux-2.6/xfs_buf.c | 8 +-------
fs/xfs/linux-2.6/xfs_buf.h | 1 -
fs/xfs/linux-2.6/xfs_fs_subr.c | 31 +++++++++++++++----------------
fs/xfs/linux-2.6/xfs_ioctl.c | 10 +++++++++-
fs/xfs/linux-2.6/xfs_ioctl32.c | 1 +
fs/xfs/linux-2.6/xfs_iops.c | 2 +-
fs/xfs/xfs_bmap.c | 26 ++++++++++++++++++++++----
fs/xfs/xfs_bmap.h | 9 ++++++---
fs/xfs/xfs_fs.h | 5 ++++-
fs/xfs/xfs_vnodeops.c | 23 ++++++++++++++++++-----
10 files changed, 77 insertions(+), 39 deletions(-)
hooks/post-receive
--
XFS development tree
_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs
