x***@oss.sgi.com
2014-08-04 04:05:43 UTC
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, xfs-misc-fixes-3.17-2 has been created
at 4ef897a27543b513351262881660147366c042a1 (commit)
- Log -----------------------------------------------------------------
commit 4ef897a27543b513351262881660147366c042a1
Author: Dave Chinner <***@redhat.com>
Date: Mon Aug 4 13:44:08 2014 +1000
xfs: flush both inodes in xfs_swap_extents
We need to treat both inodes identically from a page cache point of
view when prepareing them for extent swapping. We don't do this
right now - we assume that one of the inodes empty, because that's
what xfs_fsr currently does. Remove this assumption from the code.
While factoring out the flushing and related checks, move the
transactions reservation to immeidately after the flushes so that we
don't need to pick up and then drop the ilock to do the transaction
reservation. There are no issues with aborting the transaction it if
the checks fail before we join the inodes to the transaction and
dirty them, so this is a safe change to make.
Signed-off-by: Dave Chinner <***@redhat.com>
Reviewed-by: Christoph Hellwig <***@lst.de>
Signed-off-by: Dave Chinner <***@fromorbit.com>
commit 812176832169c77b4bacddd01edc3e55340263fd
Author: Dave Chinner <***@redhat.com>
Date: Mon Aug 4 13:29:32 2014 +1000
xfs: fix swapext ilock deadlock
xfs_swap_extents() holds the ilock over a call to
filemap_write_and_wait(), which can then try to write data and take
the ilock. That causes a self-deadlock.
Fix the deadlock and clean up the code by separating the locking
appropriately. Add a lockflags variable to track what locks we are
holding as we gain and drop them and cleanup the error handling to
always use "out_unlock" with the lockflags variable.
Signed-off-by: Dave Chinner <***@redhat.com>
Reviewed-by: Christoph Hellwig <***@lst.de>
Signed-off-by: Dave Chinner <***@fromorbit.com>
commit b92cc59f69537f26d5a42e4171ccc864ae4d9383
Author: Dave Chinner <***@redhat.com>
Date: Mon Aug 4 13:28:20 2014 +1000
xfs: kill xfs_vnode.h
Move the IO flag definitions to xfs_inode.h and kill the header file
as it is now empty.
Removing the xfs_vnode.h file showed up an implicit header include
path:
xfs_linux.h -> xfs_vnode.h -> xfs_fs.h
And so every xfs header file has been inplicitly been including
xfs_fs.h where it is needed or not. Hence the removal of xfs_vnode.h
causes all sorts of build issues because BBTOB() and friends are no
longer automatically included in the build. This also gets fixed.
Signed-off-by: Dave Chinner <***@redhat.com>
Reviewed-by: Christoph Hellwig <***@lst.de>
Signed-off-by: Dave Chinner <***@fromorbit.com>
commit dd8c38bab0d88615e0bdf013e6de3d4345f8cda2
Author: Dave Chinner <***@redhat.com>
Date: Mon Aug 4 13:23:35 2014 +1000
xfs: kill VN_MAPPED
Only one user, no longer needed.
Signed-off-by: Dave Chinner <***@redhat.com>
Reviewed-by: Christoph Hellwig <***@lst.de>
Signed-off-by: Dave Chinner <***@fromorbit.com>
commit 2667c6f935d979cea1ab7fa58568fd0fd725525f
Author: Dave Chinner <***@redhat.com>
Date: Mon Aug 4 13:23:15 2014 +1000
xfs: kill VN_CACHED
Only has 2 users, has outlived it's usefulness.
Signed-off-by: Dave Chinner <***@redhat.com>
Reviewed-by: Christoph Hellwig <***@lst.de>
Signed-off-by: Dave Chinner <***@fromorbit.com>
commit eac152b4742ec5f1ed04d73d699ae2be3607d56b
Author: Dave Chinner <***@redhat.com>
Date: Mon Aug 4 13:22:49 2014 +1000
xfs: kill VN_DIRTY()
Only one user of the macro and the dirty mapping check is redundant
so just get rid of it.
Signed-off-by: Dave Chinner <***@redhat.com>
Reviewed-by: Christoph Hellwig <***@lst.de>
Signed-off-by: Dave Chinner <***@fromorbit.com>
commit ad3714b82c631a34724da09a7daa53afcab952fa
Author: Dave Chinner <***@redhat.com>
Date: Mon Aug 4 12:59:31 2014 +1000
xfs: dquot recovery needs verifiers
dquot recovery should add verifiers to the dquot buffers that it
recovers changes into. Unfortunately, it doesn't attached the
verifiers to the buffers in a consistent manner. For example,
xlog_recover_dquot_pass2() reads dquot buffers without a verifier
and then writes it without ever having attached a verifier to the
buffer.
Further, dquot buffer recovery may write a dquot buffer that has not
been modified, or indeed, shoul dbe written because quotas are not
enabled and hence changes to the buffer were not replayed. In this
case, we again write buffers without verifiers attached because that
doesn't happen until after the buffer changes have been replayed.
Signed-off-by: Dave Chinner <***@redhat.com>
Reviewed-by: Brian Foster <***@redhat.com>
Signed-off-by: Dave Chinner <***@fromorbit.com>
commit 5fd364fee81a7888af806e42ed8a91c845894f2d
Author: Dave Chinner <***@redhat.com>
Date: Mon Aug 4 12:43:26 2014 +1000
xfs: quotacheck leaves dquot buffers without verifiers
When running xfs/305, I noticed that quotacheck was flushing dquot
buffers that did not have the xfs_dquot_buf_ops verifiers attached:
XFS (vdb): _xfs_buf_ioapply: no ops on block 0x1dc8/0x1dc8
ffff880052489000: 44 51 01 04 00 00 65 b8 00 00 00 00 00 00 00 00 DQ....e.........
ffff880052489010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
ffff880052489020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
ffff880052489030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
CPU: 1 PID: 2376 Comm: mount Not tainted 3.16.0-rc2-dgc+ #306
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
ffff88006fe38000 ffff88004a0ffae8 ffffffff81cf1cca 0000000000000001
ffff88004a0ffb88 ffffffff814d50ca 000010004a0ffc70 0000000000000000
ffff88006be56dc4 0000000000000021 0000000000001dc8 ffff88007c773d80
Call Trace:
[<ffffffff81cf1cca>] dump_stack+0x45/0x56
[<ffffffff814d50ca>] _xfs_buf_ioapply+0x3ca/0x3d0
[<ffffffff810db520>] ? wake_up_state+0x20/0x20
[<ffffffff814d51f5>] ? xfs_bdstrat_cb+0x55/0xb0
[<ffffffff814d513b>] xfs_buf_iorequest+0x6b/0xd0
[<ffffffff814d51f5>] xfs_bdstrat_cb+0x55/0xb0
[<ffffffff814d53ab>] __xfs_buf_delwri_submit+0x15b/0x220
[<ffffffff814d6040>] ? xfs_buf_delwri_submit+0x30/0x90
[<ffffffff814d6040>] xfs_buf_delwri_submit+0x30/0x90
[<ffffffff8150f89d>] xfs_qm_quotacheck+0x17d/0x3c0
[<ffffffff81510591>] xfs_qm_mount_quotas+0x151/0x1e0
[<ffffffff814ed01c>] xfs_mountfs+0x56c/0x7d0
[<ffffffff814f0f12>] xfs_fs_fill_super+0x2c2/0x340
[<ffffffff811c9fe4>] mount_bdev+0x194/0x1d0
[<ffffffff814f0c50>] ? xfs_finish_flags+0x170/0x170
[<ffffffff814ef0f5>] xfs_fs_mount+0x15/0x20
[<ffffffff811ca8c9>] mount_fs+0x39/0x1b0
[<ffffffff811e4d67>] vfs_kern_mount+0x67/0x120
[<ffffffff811e757e>] do_mount+0x23e/0xad0
[<ffffffff8117abde>] ? __get_free_pages+0xe/0x50
[<ffffffff811e71e6>] ? copy_mount_options+0x36/0x150
[<ffffffff811e8103>] SyS_mount+0x83/0xc0
[<ffffffff81cfd40b>] tracesys+0xdd/0xe2
This was caused by dquot buffer readahead not attaching a verifier
structure to the buffer when readahead was issued, resulting in the
followup read of the buffer finding a valid buffer and so not
attaching new verifiers to the buffer as part of the read.
Also, when a verifier failure occurs, we then read the buffer
without verifiers. Attach the verifiers manually after this read so
that if the buffer is then written it will be verified that the
corruption has been repaired.
Further, when flushing a dquot we don't ask for a verifier when
reading in the dquot buffer the dquot belongs to. Most of the time
this isn't an issue because the buffer is still cached, but when it
is not cached it will result in writing the dquot buffer without
having the verfier attached.
Signed-off-by: Dave Chinner <***@redhat.com>
Reviewed-by: Brian Foster <***@redhat.com>
Reviewed-by: Christoph Hellwig <***@lst.de>
Signed-off-by: Dave Chinner <***@fromorbit.com>
commit 67dc288c21064b31a98a53dc64f6b9714b819fd6
Author: Dave Chinner <***@redhat.com>
Date: Mon Aug 4 12:43:06 2014 +1000
xfs: ensure verifiers are attached to recovered buffers
Crash testing of CRC enabled filesystems has resulted in a number of
reports of bad CRCs being detected after the filesystem was mounted.
Errors such as the following were being seen:
XFS (sdb3): Mounting V5 Filesystem
XFS (sdb3): Starting recovery (logdev: internal)
XFS (sdb3): Metadata CRC error detected at xfs_agf_read_verify+0x5a/0x100 [xfs], block 0x1
XFS (sdb3): Unmount and run xfs_repair
XFS (sdb3): First 64 bytes of corrupted metadata buffer:
ffff880136ffd600: 58 41 47 46 00 00 00 01 00 00 00 00 00 0f aa 40 XAGF...........@
ffff880136ffd610: 00 02 6d 53 00 02 77 f8 00 00 00 00 00 00 00 01 ..mS..w.........
ffff880136ffd620: 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 03 ................
ffff880136ffd630: 00 00 00 04 00 08 81 d0 00 08 81 a7 00 00 00 00 ................
XFS (sdb3): metadata I/O error: block 0x1 ("xfs_trans_read_buf_map") error 74 numblks 1
The errors were typically being seen in AGF, AGI and their related
btree block buffers some time after log recovery had run. Often it
wasn't until later subsequent mounts that the problem was
discovered. The common symptom was a buffer with the correct
contents, but a CRC and an LSN that matched an older version of the
contents.
Some debug added to _xfs_buf_ioapply() indicated that buffers were
being written without verifiers attached to them from log recovery,
and Jan Kara isolated the cause to log recovery readahead an dit's
interactions with buffers that had a more recent LSN on disk than
the transaction being recovered. In this case, the buffer did not
get a verifier attached, and os when the second phase of log
recovery ran and recovered EFIs and unlinked inodes, the buffers
were modified and written without the verifier running. Hence they
had up to date contents, but stale LSNs and CRCs.
Fix it by attaching verifiers to buffers we skip due to future LSN
values so they don't escape into the buffer cache without the
correct verifier attached.
This patch is based on analysis and a patch from Jan Kara.
cc: <***@vger.kernel.org>
Reported-by: Jan Kara <***@suse.cz>
Reported-by: Fanael Linithien <***@gmail.com>
Reported-by: Grozdan <***@gmail.com>
Signed-off-by: Dave Chinner <***@redhat.com>
Reviewed-by: Brian Foster <***@redhat.com>
Reviewed-by: Christoph Hellwig <***@lst.de>
Signed-off-by: Dave Chinner <***@fromorbit.com>
commit 400b9d88757c0bfbdfa97014e090ec40a31c1282
Author: Dave Chinner <***@redhat.com>
Date: Mon Aug 4 12:42:40 2014 +1000
xfs: catch buffers written without verifiers attached
We recently had a bug where buffers were slipping through log
recovery without any verifier attached to them. This was resulting
in on-disk CRC mismatches for valid data. Add some warning code to
catch this occurrence so that we catch such bugs during development
rather than not being aware they exist.
Note that we cannot do this verification unconditionally as non-CRC
filesystems don't always attach verifiers to the buffers being
written. e.g. during log recovery we cannot identify all the
different types of buffers correctly on non-CRC filesystems, so we
can't attach the correct verifiers in all cases and so we don't
attach any. Hence we don't want on non-CRC filesystems to avoid
spamming the logs with false indications.
Signed-off-by: Dave Chinner <***@redhat.com>
Reviewed-by: Brian Foster <***@redhat.com>
Reviewed-by: Christoph Hellwig <***@lst.de>
Signed-off-by: Dave Chinner <***@fromorbit.com>
commit 5ef828c4152726f56751c78ea844f08d2b2a4fa3
Author: Eric Sandeen <***@sandeen.net>
Date: Mon Aug 4 11:35:44 2014 +1000
xfs: avoid false quotacheck after unclean shutdown
The commit
83e782e xfs: Remove incore use of XFS_OQUOTA_ENFD and XFS_OQUOTA_CHKD
added a new function xfs_sb_quota_from_disk() which swaps
on-disk XFS_OQUOTA_* flags for in-core XFS_GQUOTA_* and XFS_PQUOTA_*
flags after the superblock is read.
However, if log recovery is required, the superblock is read again,
and the modified in-core flags are re-read from disk, so we have
XFS_OQUOTA_* flags in memory again. This causes the
XFS_QM_NEED_QUOTACHECK() test to be true, because the XFS_OQUOTA_CHKD
is still set, and not XFS_GQUOTA_CHKD or XFS_PQUOTA_CHKD.
Change xfs_sb_from_disk to call xfs_sb_quota_from disk and always
convert the disk flags to in-memory flags.
Add a lower-level function which can be called with "false" to
not convert the flags, so that the sb verifier can verify
exactly what was on disk, per Brian Foster's suggestion.
Reported-by: Cyril B. <***@excellency.fr>
Signed-off-by: Eric Sandeen <***@redhat.com>
commit eedf32bfcace7d8e20cc66757d74fc68f3439ff7
Author: Brian Foster <***@redhat.com>
Date: Mon Aug 4 11:35:35 2014 +1000
xfs: fix rounding error of fiemap length parameter
The offset and length parameters are converted from bytes to basic
blocks by xfs_vn_fiemap(). The BTOBB() converter rounds the value up to
the nearest basic block. This leads to unexpected behavior when
unaligned offsets are provided to FIEMAP.
Fix the conversions of byte values to block values to cover the provided
offsets. Round down the start offset to the nearest basic block.
Calculate the end offset based on the provided values, round up and
calculate length based on the start block offset.
Reported-by: Chandan Rajendra <***@linux.vnet.ibm.com>
Signed-off-by: Brian Foster <***@redhat.com>
Reviewed-by: Dave Chinner <***@redhat.com>
Signed-off-by: Dave Chinner <***@fromorbit.com>
-----------------------------------------------------------------------
hooks/post-receive
generated because a ref change was pushed to the repository containing
the project "XFS development tree".
The branch, xfs-misc-fixes-3.17-2 has been created
at 4ef897a27543b513351262881660147366c042a1 (commit)
- Log -----------------------------------------------------------------
commit 4ef897a27543b513351262881660147366c042a1
Author: Dave Chinner <***@redhat.com>
Date: Mon Aug 4 13:44:08 2014 +1000
xfs: flush both inodes in xfs_swap_extents
We need to treat both inodes identically from a page cache point of
view when prepareing them for extent swapping. We don't do this
right now - we assume that one of the inodes empty, because that's
what xfs_fsr currently does. Remove this assumption from the code.
While factoring out the flushing and related checks, move the
transactions reservation to immeidately after the flushes so that we
don't need to pick up and then drop the ilock to do the transaction
reservation. There are no issues with aborting the transaction it if
the checks fail before we join the inodes to the transaction and
dirty them, so this is a safe change to make.
Signed-off-by: Dave Chinner <***@redhat.com>
Reviewed-by: Christoph Hellwig <***@lst.de>
Signed-off-by: Dave Chinner <***@fromorbit.com>
commit 812176832169c77b4bacddd01edc3e55340263fd
Author: Dave Chinner <***@redhat.com>
Date: Mon Aug 4 13:29:32 2014 +1000
xfs: fix swapext ilock deadlock
xfs_swap_extents() holds the ilock over a call to
filemap_write_and_wait(), which can then try to write data and take
the ilock. That causes a self-deadlock.
Fix the deadlock and clean up the code by separating the locking
appropriately. Add a lockflags variable to track what locks we are
holding as we gain and drop them and cleanup the error handling to
always use "out_unlock" with the lockflags variable.
Signed-off-by: Dave Chinner <***@redhat.com>
Reviewed-by: Christoph Hellwig <***@lst.de>
Signed-off-by: Dave Chinner <***@fromorbit.com>
commit b92cc59f69537f26d5a42e4171ccc864ae4d9383
Author: Dave Chinner <***@redhat.com>
Date: Mon Aug 4 13:28:20 2014 +1000
xfs: kill xfs_vnode.h
Move the IO flag definitions to xfs_inode.h and kill the header file
as it is now empty.
Removing the xfs_vnode.h file showed up an implicit header include
path:
xfs_linux.h -> xfs_vnode.h -> xfs_fs.h
And so every xfs header file has been inplicitly been including
xfs_fs.h where it is needed or not. Hence the removal of xfs_vnode.h
causes all sorts of build issues because BBTOB() and friends are no
longer automatically included in the build. This also gets fixed.
Signed-off-by: Dave Chinner <***@redhat.com>
Reviewed-by: Christoph Hellwig <***@lst.de>
Signed-off-by: Dave Chinner <***@fromorbit.com>
commit dd8c38bab0d88615e0bdf013e6de3d4345f8cda2
Author: Dave Chinner <***@redhat.com>
Date: Mon Aug 4 13:23:35 2014 +1000
xfs: kill VN_MAPPED
Only one user, no longer needed.
Signed-off-by: Dave Chinner <***@redhat.com>
Reviewed-by: Christoph Hellwig <***@lst.de>
Signed-off-by: Dave Chinner <***@fromorbit.com>
commit 2667c6f935d979cea1ab7fa58568fd0fd725525f
Author: Dave Chinner <***@redhat.com>
Date: Mon Aug 4 13:23:15 2014 +1000
xfs: kill VN_CACHED
Only has 2 users, has outlived it's usefulness.
Signed-off-by: Dave Chinner <***@redhat.com>
Reviewed-by: Christoph Hellwig <***@lst.de>
Signed-off-by: Dave Chinner <***@fromorbit.com>
commit eac152b4742ec5f1ed04d73d699ae2be3607d56b
Author: Dave Chinner <***@redhat.com>
Date: Mon Aug 4 13:22:49 2014 +1000
xfs: kill VN_DIRTY()
Only one user of the macro and the dirty mapping check is redundant
so just get rid of it.
Signed-off-by: Dave Chinner <***@redhat.com>
Reviewed-by: Christoph Hellwig <***@lst.de>
Signed-off-by: Dave Chinner <***@fromorbit.com>
commit ad3714b82c631a34724da09a7daa53afcab952fa
Author: Dave Chinner <***@redhat.com>
Date: Mon Aug 4 12:59:31 2014 +1000
xfs: dquot recovery needs verifiers
dquot recovery should add verifiers to the dquot buffers that it
recovers changes into. Unfortunately, it doesn't attached the
verifiers to the buffers in a consistent manner. For example,
xlog_recover_dquot_pass2() reads dquot buffers without a verifier
and then writes it without ever having attached a verifier to the
buffer.
Further, dquot buffer recovery may write a dquot buffer that has not
been modified, or indeed, shoul dbe written because quotas are not
enabled and hence changes to the buffer were not replayed. In this
case, we again write buffers without verifiers attached because that
doesn't happen until after the buffer changes have been replayed.
Signed-off-by: Dave Chinner <***@redhat.com>
Reviewed-by: Brian Foster <***@redhat.com>
Signed-off-by: Dave Chinner <***@fromorbit.com>
commit 5fd364fee81a7888af806e42ed8a91c845894f2d
Author: Dave Chinner <***@redhat.com>
Date: Mon Aug 4 12:43:26 2014 +1000
xfs: quotacheck leaves dquot buffers without verifiers
When running xfs/305, I noticed that quotacheck was flushing dquot
buffers that did not have the xfs_dquot_buf_ops verifiers attached:
XFS (vdb): _xfs_buf_ioapply: no ops on block 0x1dc8/0x1dc8
ffff880052489000: 44 51 01 04 00 00 65 b8 00 00 00 00 00 00 00 00 DQ....e.........
ffff880052489010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
ffff880052489020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
ffff880052489030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
CPU: 1 PID: 2376 Comm: mount Not tainted 3.16.0-rc2-dgc+ #306
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
ffff88006fe38000 ffff88004a0ffae8 ffffffff81cf1cca 0000000000000001
ffff88004a0ffb88 ffffffff814d50ca 000010004a0ffc70 0000000000000000
ffff88006be56dc4 0000000000000021 0000000000001dc8 ffff88007c773d80
Call Trace:
[<ffffffff81cf1cca>] dump_stack+0x45/0x56
[<ffffffff814d50ca>] _xfs_buf_ioapply+0x3ca/0x3d0
[<ffffffff810db520>] ? wake_up_state+0x20/0x20
[<ffffffff814d51f5>] ? xfs_bdstrat_cb+0x55/0xb0
[<ffffffff814d513b>] xfs_buf_iorequest+0x6b/0xd0
[<ffffffff814d51f5>] xfs_bdstrat_cb+0x55/0xb0
[<ffffffff814d53ab>] __xfs_buf_delwri_submit+0x15b/0x220
[<ffffffff814d6040>] ? xfs_buf_delwri_submit+0x30/0x90
[<ffffffff814d6040>] xfs_buf_delwri_submit+0x30/0x90
[<ffffffff8150f89d>] xfs_qm_quotacheck+0x17d/0x3c0
[<ffffffff81510591>] xfs_qm_mount_quotas+0x151/0x1e0
[<ffffffff814ed01c>] xfs_mountfs+0x56c/0x7d0
[<ffffffff814f0f12>] xfs_fs_fill_super+0x2c2/0x340
[<ffffffff811c9fe4>] mount_bdev+0x194/0x1d0
[<ffffffff814f0c50>] ? xfs_finish_flags+0x170/0x170
[<ffffffff814ef0f5>] xfs_fs_mount+0x15/0x20
[<ffffffff811ca8c9>] mount_fs+0x39/0x1b0
[<ffffffff811e4d67>] vfs_kern_mount+0x67/0x120
[<ffffffff811e757e>] do_mount+0x23e/0xad0
[<ffffffff8117abde>] ? __get_free_pages+0xe/0x50
[<ffffffff811e71e6>] ? copy_mount_options+0x36/0x150
[<ffffffff811e8103>] SyS_mount+0x83/0xc0
[<ffffffff81cfd40b>] tracesys+0xdd/0xe2
This was caused by dquot buffer readahead not attaching a verifier
structure to the buffer when readahead was issued, resulting in the
followup read of the buffer finding a valid buffer and so not
attaching new verifiers to the buffer as part of the read.
Also, when a verifier failure occurs, we then read the buffer
without verifiers. Attach the verifiers manually after this read so
that if the buffer is then written it will be verified that the
corruption has been repaired.
Further, when flushing a dquot we don't ask for a verifier when
reading in the dquot buffer the dquot belongs to. Most of the time
this isn't an issue because the buffer is still cached, but when it
is not cached it will result in writing the dquot buffer without
having the verfier attached.
Signed-off-by: Dave Chinner <***@redhat.com>
Reviewed-by: Brian Foster <***@redhat.com>
Reviewed-by: Christoph Hellwig <***@lst.de>
Signed-off-by: Dave Chinner <***@fromorbit.com>
commit 67dc288c21064b31a98a53dc64f6b9714b819fd6
Author: Dave Chinner <***@redhat.com>
Date: Mon Aug 4 12:43:06 2014 +1000
xfs: ensure verifiers are attached to recovered buffers
Crash testing of CRC enabled filesystems has resulted in a number of
reports of bad CRCs being detected after the filesystem was mounted.
Errors such as the following were being seen:
XFS (sdb3): Mounting V5 Filesystem
XFS (sdb3): Starting recovery (logdev: internal)
XFS (sdb3): Metadata CRC error detected at xfs_agf_read_verify+0x5a/0x100 [xfs], block 0x1
XFS (sdb3): Unmount and run xfs_repair
XFS (sdb3): First 64 bytes of corrupted metadata buffer:
ffff880136ffd600: 58 41 47 46 00 00 00 01 00 00 00 00 00 0f aa 40 XAGF...........@
ffff880136ffd610: 00 02 6d 53 00 02 77 f8 00 00 00 00 00 00 00 01 ..mS..w.........
ffff880136ffd620: 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 03 ................
ffff880136ffd630: 00 00 00 04 00 08 81 d0 00 08 81 a7 00 00 00 00 ................
XFS (sdb3): metadata I/O error: block 0x1 ("xfs_trans_read_buf_map") error 74 numblks 1
The errors were typically being seen in AGF, AGI and their related
btree block buffers some time after log recovery had run. Often it
wasn't until later subsequent mounts that the problem was
discovered. The common symptom was a buffer with the correct
contents, but a CRC and an LSN that matched an older version of the
contents.
Some debug added to _xfs_buf_ioapply() indicated that buffers were
being written without verifiers attached to them from log recovery,
and Jan Kara isolated the cause to log recovery readahead an dit's
interactions with buffers that had a more recent LSN on disk than
the transaction being recovered. In this case, the buffer did not
get a verifier attached, and os when the second phase of log
recovery ran and recovered EFIs and unlinked inodes, the buffers
were modified and written without the verifier running. Hence they
had up to date contents, but stale LSNs and CRCs.
Fix it by attaching verifiers to buffers we skip due to future LSN
values so they don't escape into the buffer cache without the
correct verifier attached.
This patch is based on analysis and a patch from Jan Kara.
cc: <***@vger.kernel.org>
Reported-by: Jan Kara <***@suse.cz>
Reported-by: Fanael Linithien <***@gmail.com>
Reported-by: Grozdan <***@gmail.com>
Signed-off-by: Dave Chinner <***@redhat.com>
Reviewed-by: Brian Foster <***@redhat.com>
Reviewed-by: Christoph Hellwig <***@lst.de>
Signed-off-by: Dave Chinner <***@fromorbit.com>
commit 400b9d88757c0bfbdfa97014e090ec40a31c1282
Author: Dave Chinner <***@redhat.com>
Date: Mon Aug 4 12:42:40 2014 +1000
xfs: catch buffers written without verifiers attached
We recently had a bug where buffers were slipping through log
recovery without any verifier attached to them. This was resulting
in on-disk CRC mismatches for valid data. Add some warning code to
catch this occurrence so that we catch such bugs during development
rather than not being aware they exist.
Note that we cannot do this verification unconditionally as non-CRC
filesystems don't always attach verifiers to the buffers being
written. e.g. during log recovery we cannot identify all the
different types of buffers correctly on non-CRC filesystems, so we
can't attach the correct verifiers in all cases and so we don't
attach any. Hence we don't want on non-CRC filesystems to avoid
spamming the logs with false indications.
Signed-off-by: Dave Chinner <***@redhat.com>
Reviewed-by: Brian Foster <***@redhat.com>
Reviewed-by: Christoph Hellwig <***@lst.de>
Signed-off-by: Dave Chinner <***@fromorbit.com>
commit 5ef828c4152726f56751c78ea844f08d2b2a4fa3
Author: Eric Sandeen <***@sandeen.net>
Date: Mon Aug 4 11:35:44 2014 +1000
xfs: avoid false quotacheck after unclean shutdown
The commit
83e782e xfs: Remove incore use of XFS_OQUOTA_ENFD and XFS_OQUOTA_CHKD
added a new function xfs_sb_quota_from_disk() which swaps
on-disk XFS_OQUOTA_* flags for in-core XFS_GQUOTA_* and XFS_PQUOTA_*
flags after the superblock is read.
However, if log recovery is required, the superblock is read again,
and the modified in-core flags are re-read from disk, so we have
XFS_OQUOTA_* flags in memory again. This causes the
XFS_QM_NEED_QUOTACHECK() test to be true, because the XFS_OQUOTA_CHKD
is still set, and not XFS_GQUOTA_CHKD or XFS_PQUOTA_CHKD.
Change xfs_sb_from_disk to call xfs_sb_quota_from disk and always
convert the disk flags to in-memory flags.
Add a lower-level function which can be called with "false" to
not convert the flags, so that the sb verifier can verify
exactly what was on disk, per Brian Foster's suggestion.
Reported-by: Cyril B. <***@excellency.fr>
Signed-off-by: Eric Sandeen <***@redhat.com>
commit eedf32bfcace7d8e20cc66757d74fc68f3439ff7
Author: Brian Foster <***@redhat.com>
Date: Mon Aug 4 11:35:35 2014 +1000
xfs: fix rounding error of fiemap length parameter
The offset and length parameters are converted from bytes to basic
blocks by xfs_vn_fiemap(). The BTOBB() converter rounds the value up to
the nearest basic block. This leads to unexpected behavior when
unaligned offsets are provided to FIEMAP.
Fix the conversions of byte values to block values to cover the provided
offsets. Round down the start offset to the nearest basic block.
Calculate the end offset based on the provided values, round up and
calculate length based on the start block offset.
Reported-by: Chandan Rajendra <***@linux.vnet.ibm.com>
Signed-off-by: Brian Foster <***@redhat.com>
Reviewed-by: Dave Chinner <***@redhat.com>
Signed-off-by: Dave Chinner <***@fromorbit.com>
-----------------------------------------------------------------------
hooks/post-receive
--
XFS development tree
XFS development tree