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
4c393a6 xfs: fix attr2 vs large data fork assert
4dd2cb4 xfs: force buffer writeback before blocking on the ilock in inode reclaim
from fa8b18edd752a8b4e9d1ee2cd615b82c93cf8bba (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 4c393a6059f8442a70512a48ce4639b882b6f6ad
Author: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Date: Sat Nov 19 17:44:30 2011 +0000
xfs: fix attr2 vs large data fork assert
With Dmitry fsstress updates I've seen very reproducible crashes in
xfs_attr_shortform_remove because xfs_attr_shortform_bytesfit claims that
the attributes would not fit inline into the inode after removing an
attribute. It turns out that we were operating on an inode with lots
of delalloc extents, and thus an if_bytes values for the data fork that
is larger than biggest possible on-disk storage for it which utterly
confuses the code near the end of xfs_attr_shortform_bytesfit.
Fix this by always allowing the current attribute fork, like we already
do for the attr1 format, given that delalloc conversion will take care
for moving either the data or attribute area out of line if it doesn't
fit at that point - or making the point moot by merging extents at this
point.
Also document the function better, and clean up some loose bits.
Reviewed-by: Dave Chinner <dchinner@xxxxxxxxxx>
Signed-off-by: Christoph Hellwig <hch@xxxxxx>
Signed-off-by: Ben Myers <bpm@xxxxxxx>
commit 4dd2cb4a28b7ab1f37163a4eba280926a13a8749
Author: Christoph Hellwig <hch@xxxxxx>
Date: Tue Nov 29 12:06:14 2011 -0600
xfs: force buffer writeback before blocking on the ilock in inode reclaim
If we are doing synchronous inode reclaim we block the VM from making
progress in memory reclaim. So if we encouter a flush locked inode
promote it in the delwri list and wake up xfsbufd to write it out now.
Without this we can get hangs of up to 30 seconds during workloads hitting
synchronous inode reclaim.
The scheme is copied from what we do for dquot reclaims.
Reported-by: Simon Kirby <sim@xxxxxxxxxx>
Signed-off-by: Christoph Hellwig <hch@xxxxxx>
Tested-by: Simon Kirby <sim@xxxxxxxxxx>
Signed-off-by: Ben Myers <bpm@xxxxxxx>
-----------------------------------------------------------------------
Summary of changes:
fs/xfs/xfs_attr_leaf.c | 64 +++++++++++++++++++++++++++++------------------
fs/xfs/xfs_inode.c | 21 +++++++++++++++
fs/xfs/xfs_inode.h | 1 +
fs/xfs/xfs_sync.c | 11 ++++++++
4 files changed, 72 insertions(+), 25 deletions(-)
hooks/post-receive
--
XFS development tree
_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs
