Skip to content
  • Dave Chinner's avatar
    xfs: handle dquot buffer readahead in log recovery correctly · 7d6a13f0
    Dave Chinner authored
    When we do dquot readahead in log recovery, we do not use a verifier
    as the underlying buffer may not have dquots in it. e.g. the
    allocation operation hasn't yet been replayed. Hence we do not want
    to fail recovery because we detect an operation to be replayed has
    not been run yet. This problem was addressed for inodes in commit
    d8914002
    
     ("xfs: inode buffers may not be valid during recovery
    readahead") but the problem was not recognised to exist for dquots
    and their buffers as the dquot readahead did not have a verifier.
    
    The result of not using a verifier is that when the buffer is then
    next read to replay a dquot modification, the dquot buffer verifier
    will only be attached to the buffer if *readahead is not complete*.
    Hence we can read the buffer, replay the dquot changes and then add
    it to the delwri submission list without it having a verifier
    attached to it. This then generates warnings in xfs_buf_ioapply(),
    which catches and warns about this case.
    
    Fix this and make it handle the same readahead verifier error cases
    as for inode buffers by adding a new readahead verifier that has a
    write operation as well as a read operation that marks the buffer as
    not done if any corruption is detected.  Also make sure we don't run
    readahead if the dquot buffer has been marked as cancelled by
    recovery.
    
    This will result in readahead either succeeding and the buffer
    having a valid write verifier, or readahead failing and the buffer
    state requiring the subsequent read to resubmit the IO with the new
    verifier.  In either case, this will result in the buffer always
    ending up with a valid write verifier on it.
    
    Note: we also need to fix the inode buffer readahead error handling
    to mark the buffer with EIO. Brian noticed the code I copied from
    there wrong during review, so fix it at the same time. Add comments
    linking the two functions that handle readahead verifier errors
    together so we don't forget this behavioural link in future.
    
    cc: <stable@vger.kernel.org> # 3.12 - current
    Signed-off-by: default avatarDave Chinner <dchinner@redhat.com>
    Reviewed-by: default avatarBrian Foster <bfoster@redhat.com>
    Signed-off-by: default avatarDave Chinner <david@fromorbit.com>
    7d6a13f0