From: Eric Biggers <ebiggers@kernel.org>
To: 常凤楠 <changfengnan@vivo.com>
Cc: "axboe@kernel.dk" <axboe@kernel.dk>,
"jaegeuk@kernel.org" <jaegeuk@kernel.org>,
linux-fscrypt@vger.kernel.org,
"linux-f2fs-devel@lists.sourceforge.net"
<linux-f2fs-devel@lists.sourceforge.net>
Subject: Re: [f2fs-dev] f2fs compressed file bio merge problem
Date: Mon, 18 Apr 2022 17:30:20 +0000 [thread overview]
Message-ID: <Yl2gLG/8U9HdRpUT@gmail.com> (raw)
In-Reply-To: <KL1PR0601MB4003AA93745F5F9A79794BE4BBF39@KL1PR0601MB4003.apcprd06.prod.outlook.com>
[+Cc linux-fscrypt]
On Mon, Apr 18, 2022 at 08:15:47AM +0000, 常凤楠 wrote:
> Hi:
> When I test seq-write on f2fs compressed file, I found it may have significant performance degradation when mount with inlinecrypt. Here is my analysis:
> f2fs write compressed file in unit of cluster, after compressed, one cluster up to have three valid pages to write. So between multi clusters, the page index couldn't be contiguous. For example, It may like this: Cluster 0 write page 0 and 1, Cluster 1 write page 4 and 5.
> In f2fs_crypt_mergeable_bio, fscrypt_mergeable_bio will check weather file logical block number is contiguous, result in multi clusters cannot be merge into one bio.
> In my test, inlinecrypt mount option may cause seq-write performance to drop by half.
> The attachment is my fio test configure file.
> This is a tricky problem for me. Is there any solution for this problem?
Thanks for clarifying that you are using f2fs compression; in your previous
message you didn't mention this
(https://lore.kernel.org/all/KL1PR0601MB4003998B841513BCAA386ADEBBEE9@KL1PR0601MB4003.apcprd06.prod.outlook.com/T/#u).
Unfortunately, I don't believe there is any practical way that we could do the
encryption differently that would result in this no longer being a problem.
This is because for adjacent clusters to have contiguous DUNs, the DUNs would
have to increment according to the compressed size, not the uncompressed size.
However, in this case it wouldn't be possible to support random-access writes,
since any write would require re-writing the entire file.
This could be provided as an option for read-only filesystems, I suppose. But I
doubt that that is your use case.
- Eric
_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
WARNING: multiple messages have this Message-ID (diff)
From: Eric Biggers <ebiggers@kernel.org>
To: 常凤楠 <changfengnan@vivo.com>
Cc: "jaegeuk@kernel.org" <jaegeuk@kernel.org>,
"chao@kernel.org" <chao@kernel.org>,
"axboe@kernel.dk" <axboe@kernel.dk>,
"linux-f2fs-devel@lists.sourceforge.net"
<linux-f2fs-devel@lists.sourceforge.net>,
linux-fscrypt@vger.kernel.org
Subject: Re: f2fs compressed file bio merge problem
Date: Mon, 18 Apr 2022 17:30:20 +0000 [thread overview]
Message-ID: <Yl2gLG/8U9HdRpUT@gmail.com> (raw)
In-Reply-To: <KL1PR0601MB4003AA93745F5F9A79794BE4BBF39@KL1PR0601MB4003.apcprd06.prod.outlook.com>
[+Cc linux-fscrypt]
On Mon, Apr 18, 2022 at 08:15:47AM +0000, 常凤楠 wrote:
> Hi:
> When I test seq-write on f2fs compressed file, I found it may have significant performance degradation when mount with inlinecrypt. Here is my analysis:
> f2fs write compressed file in unit of cluster, after compressed, one cluster up to have three valid pages to write. So between multi clusters, the page index couldn't be contiguous. For example, It may like this: Cluster 0 write page 0 and 1, Cluster 1 write page 4 and 5.
> In f2fs_crypt_mergeable_bio, fscrypt_mergeable_bio will check weather file logical block number is contiguous, result in multi clusters cannot be merge into one bio.
> In my test, inlinecrypt mount option may cause seq-write performance to drop by half.
> The attachment is my fio test configure file.
> This is a tricky problem for me. Is there any solution for this problem?
Thanks for clarifying that you are using f2fs compression; in your previous
message you didn't mention this
(https://lore.kernel.org/all/KL1PR0601MB4003998B841513BCAA386ADEBBEE9@KL1PR0601MB4003.apcprd06.prod.outlook.com/T/#u).
Unfortunately, I don't believe there is any practical way that we could do the
encryption differently that would result in this no longer being a problem.
This is because for adjacent clusters to have contiguous DUNs, the DUNs would
have to increment according to the compressed size, not the uncompressed size.
However, in this case it wouldn't be possible to support random-access writes,
since any write would require re-writing the entire file.
This could be provided as an option for read-only filesystems, I suppose. But I
doubt that that is your use case.
- Eric
next parent reply other threads:[~2022-04-18 17:30 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <KL1PR0601MB4003AA93745F5F9A79794BE4BBF39@KL1PR0601MB4003.apcprd06.prod.outlook.com>
2022-04-18 17:30 ` Eric Biggers [this message]
2022-04-18 17:30 ` f2fs compressed file bio merge problem Eric Biggers
2022-04-19 2:48 ` [f2fs-dev] " 常凤楠 via Linux-f2fs-devel
2022-04-19 2:48 ` 常凤楠
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=Yl2gLG/8U9HdRpUT@gmail.com \
--to=ebiggers@kernel.org \
--cc=axboe@kernel.dk \
--cc=changfengnan@vivo.com \
--cc=jaegeuk@kernel.org \
--cc=linux-f2fs-devel@lists.sourceforge.net \
--cc=linux-fscrypt@vger.kernel.org \
/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.