summaryrefslogtreecommitdiffstats
path: root/fs/reiserfs
diff options
context:
space:
mode:
authorDave Chinner <dchinner@redhat.com>2010-04-13 07:06:44 +0200
committerAlex Elder <aelder@sgi.com>2010-04-16 20:51:23 +0200
commitb6f8dd49dbdbfa60a33bba3d4b766fe341109b4b (patch)
tree75e492661ba039ce6a2d36277cccc41a27205384 /fs/reiserfs
parentMerge branch 'x86-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kern... (diff)
downloadlinux-b6f8dd49dbdbfa60a33bba3d4b766fe341109b4b.tar.xz
linux-b6f8dd49dbdbfa60a33bba3d4b766fe341109b4b.zip
xfs: ensure that sync updates the log tail correctly
Updates to the VFS layer removed an extra ->sync_fs call into the filesystem during the sync process (from the quota code). Unfortunately the sync code was unknowingly relying on this call to make sure metadata buffers were flushed via a xfs_buftarg_flush() call to move the tail of the log forward in memory before the final transactions of the sync process were issued. As a result, the old code would write a very recent log tail value to the log by the end of the sync process, and so a subsequent crash would leave nothing for log recovery to do. Hence in qa test 182, log recovery only replayed a small handle for inode fsync transactions in this case. However, with the removal of the extra ->sync_fs call, the log tail was now not moved forward with the inode fsync transactions near the end of the sync procese the first (and only) buftarg flush occurred after these transactions went to disk. The result is that log recovery now sees a large number of transactions for metadata that is already on disk. This usually isn't a problem, but when the transactions include inode chunk allocation, the inode create transactions and all subsequent changes are replayed as we cannt rely on what is on disk is valid. As a result, if the inode was written and contains unlogged changes, the unlogged changes are lost, thereby violating sync semantics. The fix is to always issue a transaction after the buftarg flush occurs is the log iѕ not idle or covered. This results in a dummy transaction being written that contains the up-to-date log tail value, which will be very recent. Indeed, it will be at least as recent as the old code would have left on disk, so log recovery will behave exactly as it used to in this situation. Signed-off-by: Dave Chinner <dchinner@redhat.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Alex Elder <aelder@sgi.com>
Diffstat (limited to 'fs/reiserfs')
0 files changed, 0 insertions, 0 deletions