From: Lukas Straub <lukasstraub2@web.de>
To: "Valdis Klētnieks" <valdis.kletnieks@vt.edu>
Cc: 오준택 <na94jun@gmail.com>, kernelnewbies@kernelnewbies.org
Subject: Re: Ordering guarantee inside a single bio?
Date: Thu, 30 Jan 2020 15:16:17 +0100 [thread overview]
Message-ID: <20200130151617.58d57aa4@luklap> (raw)
In-Reply-To: <47803.1580329717@turing-police>
On Wed, 29 Jan 2020 15:28:37 -0500
"Valdis Klētnieks" <valdis.kletnieks@vt.edu> wrote:
> [...]
>
> Questions for Lukas:
>
> First off, see my comment about -EIO. Do you have plans for an ioctl or
> other way for userspace to get the two checksums so diagnostic programs
> can do better error diagnosis/recovery?
Not really, but as I will integrate it with the existing dm-integrity
infrastructure it will support the recovery mode which won't check the
checksums.
Recovery will more or less happen as you described it above.
> If I understand what you're doing, each 4096 (or whatever) block will actually
> take (4096 + 2* checksum size) bytes, which means each logical consecutive
> block will be offset from the start of a physical block by some amount. This
> effectively means that you are guaranteed one read-modify-write and possibly
> two, for each write. (The other alternative is to devote an entire block to
> each checksum, but that triples the size and at that point you may as well just
> do a 2+1 raidset)
No, csum_next (and csum_prev) is a whole sector (i.e. physical block)
containing all the checksums for the following chunk of data (which
spans multiple sectors), so pretty similar to the current dm-integrity
implementation apart from the 2nd checksum sector.
RMW is only needed for the checksum sector and because they don't take
up much space, they are easily cached in ram so only needing the write
in the best case.
Regarding the ordering guarantee, I have now gathered that the kernel
will happily split the bio if the size is not optimal for the hardware
which means it's not guaranteed - right?
_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
next prev parent reply other threads:[~2020-01-30 14:17 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-26 12:07 Ordering guarantee inside a single bio? Lukas Straub
2020-01-27 17:27 ` Valdis Klētnieks
2020-01-27 18:22 ` Lukas Straub
2020-01-28 4:50 ` 오준택
2020-01-29 20:28 ` Valdis Klētnieks
2020-01-30 14:16 ` Lukas Straub [this message]
2020-01-31 3:26 ` Valdis Klētnieks
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=20200130151617.58d57aa4@luklap \
--to=lukasstraub2@web.de \
--cc=kernelnewbies@kernelnewbies.org \
--cc=na94jun@gmail.com \
--cc=valdis.kletnieks@vt.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).