summaryrefslogtreecommitdiff
path: root/CREDITS
diff options
context:
space:
mode:
authorDave Chinner <dchinner@redhat.com>2013-06-03 05:28:46 (GMT)
committerBen Myers <bpm@sgi.com>2013-06-06 15:50:35 (GMT)
commitbb9b8e86ad083ecb2567ae909c1d6cb0bbaa60fe (patch)
tree032c32322f3be1e866655ea69bf897099be01c55 /CREDITS
parent7bc0dc271e494e12be3afd3c6431e5216347c624 (diff)
downloadlinux-bb9b8e86ad083ecb2567ae909c1d6cb0bbaa60fe.tar.xz
xfs: rework dquot CRCs
Calculating dquot CRCs when the backing buffer is written back just doesn't work reliably. There are several places which manipulate dquots directly in the buffers, and they don't calculate CRCs appropriately, nor do they always set the buffer up to calculate CRCs appropriately. Firstly, if we log a dquot buffer (e.g. during allocation) it gets logged without valid CRC, and so on recovery we end up with a dquot that is not valid. Secondly, if we recover/repair a dquot, we don't have a verifier attached to the buffer and hence CRCs are not calculated on the way down to disk. Thirdly, calculating the CRC after we've changed the contents means that if we re-read the dquot from the buffer, we cannot verify the contents of the dquot are valid, as the CRC is invalid. So, to avoid all the dquot CRC errors that are being detected by the read verifier, change to using the same model as for inodes. That is, dquot CRCs are calculated and written to the backing buffer at the time the dquot is flushed to the backing buffer. If we modify the dquot directly in the backing buffer, calculate the CRC immediately after the modification is complete. Hence the dquot in the on-disk buffer should always have a valid CRC. Signed-off-by: Dave Chinner <dchinner@redhat.com> Reviewed-by: Brian Foster <bfoster@redhat.com> Reviewed-by: Ben Myers <bpm@sgi.com> Signed-off-by: Ben Myers <bpm@sgi.com> (cherry picked from commit 6fcdc59de28817d1fbf1bd58cc01f4f3fac858fb)
Diffstat (limited to 'CREDITS')
0 files changed, 0 insertions, 0 deletions