Messages in this thread | | | Date | Wed, 21 Jul 2021 10:53:58 +0800 | From | Gao Xiang <> | Subject | Re: [PATCH v4] iomap: support tail packing inline read |
| |
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
| |