From: "Arkadiusz Miśkiewicz" <arekm@maven.pl>
To: xfs@oss.sgi.com
Subject: Re: [PATCH] xfs: handle dquot buffer readahead in log recovery correctly
Date: Wed, 6 Jan 2016 17:16:44 +0100 [thread overview]
Message-ID: <201601061716.44402.arekm@maven.pl> (raw)
In-Reply-To: <1452052834-20605-1-git-send-email-david@fromorbit.com>
On Wednesday 06 of January 2016, Dave Chinner wrote:
> From: Dave Chinner <dchinner@redhat.com>
>
> 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
> d891400 ("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.
Checked this patch on 4.1.15.
When the issue occured I started seeing thousands of "_xfs_buf_ioapply: no ops
on block ..." entries in logs.
With this patch these are all gone.
--
Arkadiusz Miśkiewicz, arekm / ( maven.pl | pld-linux.org )
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2016-01-06 16:16 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-06 4:00 [PATCH] xfs: handle dquot buffer readahead in log recovery correctly Dave Chinner
2016-01-06 14:34 ` Brian Foster
2016-01-06 22:24 ` Dave Chinner
2016-01-06 16:16 ` Arkadiusz Miśkiewicz [this message]
2016-01-07 3:08 ` [PATCH v2] " Dave Chinner
2016-01-07 12:44 ` Brian Foster
2016-01-07 23:55 ` Dave Chinner
2016-01-08 12:39 ` Brian Foster
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201601061716.44402.arekm@maven.pl \
--to=arekm@maven.pl \
--cc=xfs@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.