linux-fscrypt.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Theodore Y. Ts'o" <tytso@mit.edu>
To: Gao Xiang <gaoxiang25@huawei.com>
Cc: Chandan Rajendra <chandan@linux.ibm.com>,
	ebiggers@kernel.org, linux-fsdevel@vger.kernel.org,
	linux-ext4@vger.kernel.org,
	linux-f2fs-devel@lists.sourceforge.net,
	linux-fscrypt@vger.kernel.org, chandanrmail@gmail.com,
	adilger.kernel@dilger.ca, jaegeuk@kernel.org, yuchao0@huawei.com,
	hch@infradead.org
Subject: Re: [PATCH V4 5/8] f2fs: Use read_callbacks for decrypting file data
Date: Tue, 20 Aug 2019 12:25:10 -0400	[thread overview]
Message-ID: <20190820162510.GC10232@mit.edu> (raw)
In-Reply-To: <20190820051236.GE159846@architecture4>

On Tue, Aug 20, 2019 at 01:12:36PM +0800, Gao Xiang wrote:
> Add a word, I have some little concern about post read procession order
> a bit as I mentioned before, because I'd like to move common EROFS
> decompression code out in the future as well for other fses to use
> after we think it's mature enough.
> 
> It seems the current code mainly addresses eliminating duplicated code,
> therefore I have no idea about that...

Actually, we should chat.  I was actually thinking about "borrowing"
code from erofs to provide ext4-specific compression.  I was really
impressed with the efficiency goals in the erofs design[1] when I
reviewed the Usenix ATC paper, and as the saying goes, the best
artists know how to steal from the best.  :-)

[1] https://www.usenix.org/conference/atc19/presentation/gao

My original specific thinking was to do code reuse by copy and paste,
simply because it was simpler, and I have limited time to work on it.
But if you are interested in making the erofs pipeline reusable by
other file systems, and have the time to do the necessary code
refactoring, I'd love to work with you on that.

It should be noted that the f2fs developers have been working on their
own compression scheme that was going to be f2fs-specific, unlike the
file system generic approach used with fsverity and fscrypt.

My expectation is that we will need to modify the read pipeling code
to support compression.  That's true whether we are looking at the
existing file system-specific code used by ext4 and f2fs or in some
combined work such as what Chandan has proposed.

Cheers,

					- Ted

  parent reply	other threads:[~2019-08-20 16:25 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-16  6:17 [PATCH V4 0/8] Consolidate FS read I/O callbacks code Chandan Rajendra
2019-08-16  6:17 ` [PATCH V4 1/8] buffer_head: Introduce BH_Read_Cb flag Chandan Rajendra
2019-08-16  6:17 ` [PATCH V4 2/8] FS: Introduce read callbacks Chandan Rajendra
2019-08-16  6:17 ` [PATCH V4 3/8] fs/mpage.c: Integrate " Chandan Rajendra
2019-08-16  6:18 ` [PATCH V4 4/8] fs/buffer.c: add decryption support via read_callbacks Chandan Rajendra
2019-08-16  6:18 ` [PATCH V4 5/8] f2fs: Use read_callbacks for decrypting file data Chandan Rajendra
2019-08-18 13:45   ` [f2fs-dev] " Chao Yu
2019-08-19 13:33     ` Chandan Rajendra
2019-08-20  7:43       ` Chao Yu
2019-08-20  5:05   ` Chandan Rajendra
2019-08-20  5:12     ` Gao Xiang
2019-08-20  5:16       ` Gao Xiang
2019-08-20 16:25       ` Theodore Y. Ts'o [this message]
2019-08-20 17:07         ` Gao Xiang
2019-08-20 16:38     ` Theodore Y. Ts'o
2019-08-20 17:31       ` Jaegeuk Kim
2019-08-21  2:04         ` Chandan Rajendra
2019-08-16  6:18 ` [PATCH V4 6/8] ext4: Wire up ext4_readpage[s] to use mpage_readpage[s] Chandan Rajendra
2019-08-16  6:18 ` [PATCH V4 7/8] ext4: Enable encryption for subpage-sized blocks Chandan Rajendra
2019-08-16  6:18 ` [PATCH V4 8/8] fscrypt: remove struct fscrypt_ctx Chandan Rajendra

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=20190820162510.GC10232@mit.edu \
    --to=tytso@mit.edu \
    --cc=adilger.kernel@dilger.ca \
    --cc=chandan@linux.ibm.com \
    --cc=chandanrmail@gmail.com \
    --cc=ebiggers@kernel.org \
    --cc=gaoxiang25@huawei.com \
    --cc=hch@infradead.org \
    --cc=jaegeuk@kernel.org \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-f2fs-devel@lists.sourceforge.net \
    --cc=linux-fscrypt@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=yuchao0@huawei.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;
as well as URLs for NNTP newsgroup(s).