[XFS updates] XFS development tree branch, master, updated. v2.6.30-rc4-34429-g153f0ca
xfs at oss.sgi.com
xfs at oss.sgi.com
Sun Jan 10 12:10:47 CST 2010
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
153f0ca xfs: Ensure we force all busy extents in range to disk
6701069 xfs: Don't flush stale inodes
996c3bc xfs: fix timestamp handling in xfs_setattr
f00fbad xfs: use DECLARE_EVENT_CLASS
from a2b63114daf490a68bc9a32dac99d1888c5de842 (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 153f0ca7b70ebf5a9726250a98d3651b6296c131
Author: Dave Chinner <david at fromorbit.com>
Date: Sat Jan 2 02:38:56 2010 +0000
xfs: Ensure we force all busy extents in range to disk
When we search for and find a busy extent during allocation we
force the log out to ensure the extent free transaction is on
disk before the allocation transaction. The current implementation
has a subtle bug in it--it does not handle multiple overlapping
ranges.
That is, if we free lots of little extents into a single
contiguous extent, then allocate the contiguous extent, the busy
search code stops searching at the first extent it finds that
overlaps the allocated range. It then uses the commit LSN of the
transaction to force the log out to.
Unfortunately, the other busy ranges might have more recent
commit LSNs than the first busy extent that is found, and this
results in xfs_alloc_search_busy() returning before all the
extent free transactions are on disk for the range being
allocated. This can lead to potential metadata corruption or
stale data exposure after a crash because log replay won't replay
all the extent free transactions that cover the allocation range.
Modified-by: Alex Elder <aelder at sgi.com>
(Dropped the "found" argument from the xfs_alloc_busysearch trace
event.)
Signed-off-by: Dave Chinner <david at fromorbit.com>
Reviewed-by: Christoph Hellwig <hch at lst.de>
Signed-off-by: Alex Elder <aelder at sgi.com>
commit 67010697af7f00dd038322bdec108e7ffd0567e8
Author: Dave Chinner <david at fromorbit.com>
Date: Sat Jan 2 02:39:40 2010 +0000
xfs: Don't flush stale inodes
Because inodes remain in cache much longer than inode buffers do
under memory pressure, we can get the situation where we have
stale, dirty inodes being reclaimed but the backing storage has
been freed. Hence we should never, ever flush XFS_ISTALE inodes
to disk as there is no guarantee that the backing buffer is in
cache and still marked stale when the flush occurs.
Signed-off-by: Dave Chinner <david at fromorbit.com>
Signed-off-by: Alex Elder <aelder at sgi.com>
commit 996c3bc089b09d1cbf15da156100210ca34f2eab
Author: Christoph Hellwig <hch at infradead.org>
Date: Wed Dec 23 16:09:13 2009 +0000
xfs: fix timestamp handling in xfs_setattr
We currently have some rather odd code in xfs_setattr for
updating the a/c/mtime timestamps:
- first we do a non-transaction update if all three are updated
together
- second we implicitly update the ctime for various changes
instead of relying on the ATTR_CTIME flag
- third we set the timestamps to the current time instead of the
arguments in the iattr structure in many cases.
This patch makes sure we update it in a consistent way:
- always transactional
- ctime is only updated if ATTR_CTIME is set or we do a size
update, which is a special case
- always to the times passed in from the caller instead of the
current time
The only non-size caller of xfs_setattr that doesn't come from
the VFS is updated to set ATTR_CTIME and pass in a valid ctime
value.
Reported-by: Eric Blake <ebb9 at byu.net>
Signed-off-by: Christoph Hellwig <hch at lst.de>
Signed-off-by: Alex Elder <aelder at sgi.com>
commit f00fbad6d00afffef9e4e9ae78494dff70923897
Author: Christoph Hellwig <hch at infradead.org>
Date: Mon Dec 21 14:03:03 2009 +0000
xfs: use DECLARE_EVENT_CLASS
Using DECLARE_EVENT_CLASS allows us to to use trace event code
instead of duplicating it in the binary. This was not available
before 2.6.33 so it had to be done as a separate step once the
prerequisite was merged.
This only requires changes to xfs_trace.h and the results are
rather impressive:
hch at brick:~/work/linux-2.6/obj-kvm$ size fs/xfs/xfs.o*
text data bss dec hex filename
607732 41884 3616 653232 9f7b0 fs/xfs/xfs.o
1026732 41884 3808 1072424 105d28 fs/xfs/xfs.o.old
Signed-off-by: Christoph Hellwig <hch at lst.de>
Signed-off-by: Alex Elder <aelder at sgi.com>
-----------------------------------------------------------------------
Summary of changes:
fs/xfs/linux-2.6/xfs_acl.c | 3 +-
fs/xfs/linux-2.6/xfs_trace.h | 1141 ++++++++++++++++++++++--------------------
fs/xfs/xfs_alloc.c | 44 +-
fs/xfs/xfs_inode.c | 10 +-
fs/xfs/xfs_vnodeops.c | 93 ++--
5 files changed, 666 insertions(+), 625 deletions(-)
hooks/post-receive
--
XFS development tree
More information about the xfs
mailing list