From: Gao Xiang <hsiangkao@linux.alibaba.com> To: "Andreas Grünbacher" <andreas.gruenbacher@gmail.com> Cc: "Darrick J. Wong" <djwong@kernel.org>, Matthew Wilcox <willy@infradead.org>, linux-erofs@lists.ozlabs.org, Linux FS-devel Mailing List <linux-fsdevel@vger.kernel.org>, LKML <linux-kernel@vger.kernel.org>, Christoph Hellwig <hch@lst.de> Subject: Re: [PATCH v4] iomap: support tail packing inline read Date: Wed, 21 Jul 2021 10:53:58 +0800 [thread overview] Message-ID: <YPeMRsJwELjoWLFs@B-P7TQMD6M-0146.local> (raw) In-Reply-To: <CAHpGcM+8cp81=bkzFf3sZfKREM9VbXfePpXrswNJOLVcwEnK7A@mail.gmail.com> Hi Andreas, On Wed, Jul 21, 2021 at 04:26:47AM +0200, Andreas Grünbacher wrote: > Am Mi., 21. Juli 2021 um 02:33 Uhr schrieb Gao Xiang > <hsiangkao@linux.alibaba.com>: > > > And since you can only kmap one page at a time, an inline read grabs the > > > first part of the data in "page one" and then we have to call > > > iomap_begin a second time get a new address so that we can read the rest > > > from "page two"? > > > > Nope, currently EROFS inline data won't cross page like this. > > > > But in principle, yes, I don't want to limit it to the current > > EROFS or gfs2 usage. I think we could make this iomap function > > more generally (I mean, I'd like to make the INLINE extent > > functionity as general as possible, > > Nono. Can we please limit this patch what we actually need right now, > and worry about extending it later? Can you elaborate what it will benefit us if we only support one tail block for iomap_read_inline_data()? (I mean it has similar LOC changes, similar implementation / complexity.) The only concern I think is if it causes gfs2 regression, so that is what I'd like to confirm. In contrast, I'd like to avoid iomap_write_begin() tail-packing because it's complex and no fs user interests in it for now. So I leave it untouched for now. Another concern I really like to convert EROFS to iomap is I'd like to support sub-page blocksize for EROFS after converting. I don't want to touch iomap inline code again like this since it interacts 2 directories thus cause too much coupling. Thanks, Gao Xiang > > > my v1 original approach > > in principle can support any inline extent in the middle of > > file rather than just tail blocks, but zeroing out post-EOF > > needs another iteration) and I don't see it add more code and > > complexity. > > Thanks, > Andreas
WARNING: multiple messages have this Message-ID (diff)
From: Gao Xiang <hsiangkao@linux.alibaba.com> To: "Andreas Grünbacher" <andreas.gruenbacher@gmail.com> Cc: "Darrick J. Wong" <djwong@kernel.org>, LKML <linux-kernel@vger.kernel.org>, Matthew Wilcox <willy@infradead.org>, Linux FS-devel Mailing List <linux-fsdevel@vger.kernel.org>, linux-erofs@lists.ozlabs.org, Christoph Hellwig <hch@lst.de> Subject: Re: [PATCH v4] iomap: support tail packing inline read Date: Wed, 21 Jul 2021 10:53:58 +0800 [thread overview] Message-ID: <YPeMRsJwELjoWLFs@B-P7TQMD6M-0146.local> (raw) In-Reply-To: <CAHpGcM+8cp81=bkzFf3sZfKREM9VbXfePpXrswNJOLVcwEnK7A@mail.gmail.com> Hi Andreas, On Wed, Jul 21, 2021 at 04:26:47AM +0200, Andreas Grünbacher wrote: > Am Mi., 21. Juli 2021 um 02:33 Uhr schrieb Gao Xiang > <hsiangkao@linux.alibaba.com>: > > > And since you can only kmap one page at a time, an inline read grabs the > > > first part of the data in "page one" and then we have to call > > > iomap_begin a second time get a new address so that we can read the rest > > > from "page two"? > > > > Nope, currently EROFS inline data won't cross page like this. > > > > But in principle, yes, I don't want to limit it to the current > > EROFS or gfs2 usage. I think we could make this iomap function > > more generally (I mean, I'd like to make the INLINE extent > > functionity as general as possible, > > Nono. Can we please limit this patch what we actually need right now, > and worry about extending it later? Can you elaborate what it will benefit us if we only support one tail block for iomap_read_inline_data()? (I mean it has similar LOC changes, similar implementation / complexity.) The only concern I think is if it causes gfs2 regression, so that is what I'd like to confirm. In contrast, I'd like to avoid iomap_write_begin() tail-packing because it's complex and no fs user interests in it for now. So I leave it untouched for now. Another concern I really like to convert EROFS to iomap is I'd like to support sub-page blocksize for EROFS after converting. I don't want to touch iomap inline code again like this since it interacts 2 directories thus cause too much coupling. Thanks, Gao Xiang > > > my v1 original approach > > in principle can support any inline extent in the middle of > > file rather than just tail blocks, but zeroing out post-EOF > > needs another iteration) and I don't see it add more code and > > complexity. > > Thanks, > Andreas
next prev parent reply other threads:[~2021-07-21 2:55 UTC|newest] Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-07-20 13:35 [PATCH v4] iomap: support tail packing inline read Gao Xiang 2021-07-20 13:35 ` Gao Xiang 2021-07-20 20:42 ` Darrick J. Wong 2021-07-20 20:42 ` Darrick J. Wong 2021-07-20 21:18 ` Matthew Wilcox 2021-07-20 21:18 ` Matthew Wilcox 2021-07-21 0:03 ` Gao Xiang 2021-07-21 0:03 ` Gao Xiang 2021-07-21 0:17 ` Darrick J. Wong 2021-07-21 0:33 ` Gao Xiang 2021-07-21 0:33 ` Gao Xiang 2021-07-21 2:26 ` Andreas Grünbacher 2021-07-21 2:26 ` Andreas Grünbacher 2021-07-21 2:53 ` Gao Xiang [this message] 2021-07-21 2:53 ` Gao Xiang 2021-07-21 6:43 ` Andreas Grünbacher 2021-07-21 7:28 ` Gao Xiang 2021-07-21 7:28 ` Gao Xiang 2021-07-21 6:33 ` Andreas Grünbacher 2021-07-21 6:33 ` Andreas Grünbacher 2021-07-20 23:46 ` Gao Xiang 2021-07-20 23:46 ` Gao Xiang
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=YPeMRsJwELjoWLFs@B-P7TQMD6M-0146.local \ --to=hsiangkao@linux.alibaba.com \ --cc=andreas.gruenbacher@gmail.com \ --cc=djwong@kernel.org \ --cc=hch@lst.de \ --cc=linux-erofs@lists.ozlabs.org \ --cc=linux-fsdevel@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=willy@infradead.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: linkBe 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.