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
297db93 xfs: fix ->write_inode return values
da6742a xfs: fix xfs_mark_inode_dirty during umount
from 57b5a91db28542a8d8a697b9e3da2bd0e062f7d3 (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 297db93bb74cf687510313eb235a7aec14d67e97
Author: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Date: Sat Aug 27 05:57:55 2011 +0000
xfs: fix ->write_inode return values
Currently we always redirty an inode that was attempted to be written out
synchronously but has been cleaned by an AIL pushed internall, which is
rather bogus. Fix that by doing the i_update_core check early on and
return 0 for it. Also include async calls for it, as doing any work for
those is just as pointless. While we're at it also fix the sign for the
EIO return in case of a filesystem shutdown, and fix the completely
non-sensical locking around xfs_log_inode.
Signed-off-by: Christoph Hellwig <hch@xxxxxx>
Reviewed-by: Dave Chinner <dchinner@xxxxxxxxxx>
Signed-off-by: Alex Elder <aelder@xxxxxxx>
commit da6742a5a4cc844a9982fdd936ddb537c0747856
Author: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Date: Sat Aug 27 05:57:44 2011 +0000
xfs: fix xfs_mark_inode_dirty during umount
During umount we do not add a dirty inode to the lru and wait for it to
become clean first, but force writeback of data and metadata with
I_WILL_FREE set. Currently there is no way for XFS to detect that the
inode has been redirtied for metadata operations, as we skip the
mark_inode_dirty call during teardown. Fix this by setting i_update_core
nanually in that case, so that the inode gets flushed during inode reclaim.
Alternatively we could enable calling mark_inode_dirty for inodes in
I_WILL_FREE state, and let the VFS dirty tracking handle this. I decided
against this as we will get better I/O patterns from reclaim compared to
the synchronous writeout in write_inode_now, and always marking the inode
dirty in some way from xfs_mark_inode_dirty is a better safetly net in
either case.
Signed-off-by: Christoph Hellwig <hch@xxxxxx>
Reviewed-by: Dave Chinner <dchinner@xxxxxxxxxx>
Signed-off-by: Alex Elder <aelder@xxxxxxx>
-----------------------------------------------------------------------
Summary of changes:
fs/xfs/xfs_iops.c | 14 +++++++++++---
fs/xfs/xfs_super.c | 34 +++++++++-------------------------
2 files changed, 20 insertions(+), 28 deletions(-)
hooks/post-receive
--
XFS development tree
_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs
