linux-xfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Martin K. Petersen" <martin.petersen@oracle.com>
To: Jens Axboe <axboe@kernel.dk>
Cc: Bob Liu <bob.liu@oracle.com>,
	"Martin K. Petersen" <martin.petersen@oracle.com>,
	linux-block@vger.kernel.org, linux-xfs@vger.kernel.org,
	linux-fsdevel@vger.kernel.org, shirley.ma@oracle.com,
	allison.henderson@oracle.com, david@fromorbit.com,
	darrick.wong@oracle.com, hch@infradead.org, adilger@dilger.ca,
	tytso@mit.edu
Subject: Re: [PATCH v3 2/3] block: verify data when endio
Date: Fri, 29 Mar 2019 22:17:22 -0400	[thread overview]
Message-ID: <yq1imw1p0lp.fsf@oracle.com> (raw)
In-Reply-To: <7599b239-46f4-9799-a87a-3ca3891d4a08@kernel.dk> (Jens Axboe's message of "Fri, 29 Mar 2019 09:03:47 -0600")


Jens,

> You will not need a callback in the bio, you will just have a private
> end_io function for that particular bio that does the verification.

The saving grace for the integrity stuff is that once all the child bios
complete, we no longer care about their completion context and we have
the parent bio submitted by the filesystem we can use to verify the PI
against.

For the redundant copy use case, however, I am guessing that the
filesystem folks would want the same thing. I.e. verify the structure of
the data received once the parent bio completes. However, at that point
all the slicing and dicing completion state is lost. And thus there is
no way to know that the failure was due to mirror B two layers down the
stack. Nor is there any way to retry the I/O without having recorded a
completion breadcrumb trail for every child bio.

The other approach is the callback where each stacking layer--which
knows about redundancy--can do verification of a bio upon completion.
However, that suffers from another headache in that the I/O can get
arbitrarily sliced and diced in units of 512 bytes. And thus the
filesystem verification function would have to be able to verify an
arbitrary multiple of 512 bytes at any 512-byte offset inside a
submitted bio. That would work, but I don't think that's the pony the
filesystem were wishing for?

-- 
Martin K. Petersen	Oracle Linux Engineering

  reply	other threads:[~2019-03-30  2:17 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-29 14:23 [RFC PATCH v3 0/3] Block/XFS: Support alternative mirror device retry Bob Liu
2019-03-29 14:23 ` [PATCH v3 1/3] block: introduce submit_bio_verify() Bob Liu
2019-03-29 22:22   ` Andreas Dilger
2019-03-30  1:43     ` Martin K. Petersen
2019-03-29 14:23 ` [PATCH v3 2/3] block: verify data when endio Bob Liu
2019-03-29 14:28   ` Jens Axboe
2019-03-29 14:34     ` Martin K. Petersen
2019-03-29 14:38       ` Jens Axboe
2019-03-29 14:46         ` Martin K. Petersen
2019-03-29 14:50           ` Jens Axboe
2019-03-29 14:51             ` Martin K. Petersen
2019-03-29 14:52               ` Jens Axboe
2019-03-29 15:00                 ` Bob Liu
2019-03-29 15:03                   ` Jens Axboe
2019-03-30  2:17                     ` Martin K. Petersen [this message]
2019-03-31 22:00                       ` Dave Chinner
2019-04-01 14:04                         ` Martin K. Petersen
2019-04-01 21:21                           ` Dave Chinner
2019-04-03  2:45                             ` Martin K. Petersen
2019-04-03 22:21                               ` Dave Chinner
2019-03-29 14:41       ` Bob Liu
2019-03-29 14:40     ` Bob Liu
2019-03-29 14:47       ` Jens Axboe
2019-03-30  0:20       ` Andreas Dilger
2019-03-29 15:39   ` Ming Lei
2019-03-29 14:23 ` [PATCH v3 3/3] fs: xfs: add read_verifier() function Bob Liu

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=yq1imw1p0lp.fsf@oracle.com \
    --to=martin.petersen@oracle.com \
    --cc=adilger@dilger.ca \
    --cc=allison.henderson@oracle.com \
    --cc=axboe@kernel.dk \
    --cc=bob.liu@oracle.com \
    --cc=darrick.wong@oracle.com \
    --cc=david@fromorbit.com \
    --cc=hch@infradead.org \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    --cc=shirley.ma@oracle.com \
    --cc=tytso@mit.edu \
    /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;
as well as URLs for NNTP newsgroup(s).