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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox