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@xxxxxxxxxxxxxxxxx>: > > > 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
