From: 常凤楠 <changfengnan@vivo.com>
To: Eric Biggers <ebiggers@kernel.org>
Cc: "tytso@mit.edu" <tytso@mit.edu>,
"jaegeuk@kernel.org" <jaegeuk@kernel.org>,
"linux-fscrypt@vger.kernel.org" <linux-fscrypt@vger.kernel.org>
Subject: RE: why fscrypt_mergeable_bio use logical block number?
Date: Sun, 17 Apr 2022 02:34:17 +0000 [thread overview]
Message-ID: <KL1PR0601MB40035814CF8324474BC543B2BBF09@KL1PR0601MB4003.apcprd06.prod.outlook.com> (raw)
In-Reply-To: <Ylm+VyMLzJ92yndr@gmail.com>
> -----Original Message-----
> From: Eric Biggers <ebiggers@kernel.org>
> Sent: Saturday, April 16, 2022 2:50 AM
> To: 常凤楠 <changfengnan@vivo.com>
> Cc: tytso@mit.edu; jaegeuk@kernel.org; linux-fscrypt@vger.kernel.org
> Subject: Re: why fscrypt_mergeable_bio use logical block number?
>
> On Fri, Apr 15, 2022 at 08:18:11AM +0000, 常凤楠 wrote:
> > Hi:
> > When I dig into a problem, I found: bio merge may reduce a lot when
> > enable inlinecrypt, the root cause is fscrypt_mergeable_bio use logical
> > block number rather than physical block number. I had read the UFSHCI,
> > but not see any description about why data unit number shoud use
> logical
> > block number. I want to know why, Is the anyone can explain this?
> >
> > Thanks.
> > Fengnan Chang.
>
> The main reason that fscrypt generates IVs using the file logical block number
> instead of the sector number is because f2fs needs to move data blocks
> around without the key. That would be impossible with sector number
> based encryption.
So if use sector number to generate IVs, after f2fs move data blocks in gc, we can
not decrypt correctly, am I right ?
>
> There are other reasons too. Always using the file logical block number
> keeps the various fscrypt options consistent, it works well with per-file keys, it
> doesn't break filesystem resizing, and it avoids having the interpretation of
> the filesystem depend on its on-disk location which would be a layering
> violation. But the need to support f2fs is the main one.
>
> Note that by default, fscrypt uses a different key for every file, and in that case
> the only way that using the file logical block number instead of the sector
> number would prevent merging is if data was being read/written from a file
> that is physically but not logically contiguous. That's not a very common
> case.
This is exactly the problem I have faced. We read/write a file in physically contiguous but not logically.
So I'm wander if we can keep physically contiguous always, can we skip check wheatear logical block
number is contiguous when bio merge?
>
> - Eric
next prev parent reply other threads:[~2022-04-17 2:34 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-15 8:18 why fscrypt_mergeable_bio use logical block number? 常凤楠
2022-04-15 18:49 ` Eric Biggers
2022-04-17 2:34 ` 常凤楠 [this message]
2022-04-18 7:25 ` Eric Biggers
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=KL1PR0601MB40035814CF8324474BC543B2BBF09@KL1PR0601MB4003.apcprd06.prod.outlook.com \
--to=changfengnan@vivo.com \
--cc=ebiggers@kernel.org \
--cc=jaegeuk@kernel.org \
--cc=linux-fscrypt@vger.kernel.org \
--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 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.