Hi Christoph,
On Fri, Aug 30, 2019 at 09:28:12AM -0700, Christoph Hellwig wrote:
> > - err = bio_add_page(bio, page, PAGE_SIZE, 0);
> > - if (err != PAGE_SIZE) {
> > + if (bio_add_page(bio, page, PAGE_SIZE, 0) != PAGE_SIZE) {
> > err = -EFAULT;
> > goto err_out;
> > }
>
> This patch looks like an improvement. But looking at that whole
> area just makes me cringe.
OK, I agree with you, I will improve it or just kill them all with
new iomap approach after it supports tail-end packing inline.
>
> Why is there __erofs_get_meta_page with the two weird booleans instead
> of a single erofs_get_meta_page that gets and gfp_t for additional
> flags and an unsigned int for additional bio op flags.
I agree with you. Thanks for your suggestion.
>
> Why do need ioprio support to start with? Seeing that in a new
> fs look kinda odd. Do you have benchmarks that show the difference?
I don't have some benchmark for all of these, can I just set
REQ_PRIO for all metadata? is that reasonable?
Could you kindly give some suggestion on this?
>
> That function then calls erofs_grab_bio, which tries to handle a
> bio_alloc failure, except that the function will not actually fail
> due the mempool backing it. It also seems like and awfully
> huge function to inline.
OK, I will simplify it. Thanks for your suggestion.
>
> Why is there __submit_bio which really just obsfucates what is
> going on? Also why is __submit_bio using bio_set_op_attrs instead
> of opencode it as the comment right next to it asks you to?
Originally, mainly due to backport consideration since some
of our smartphones use 3.x kernel as well...
>
> Also I really don't understand why you can't just use read_cache_page
> or even read_cache_page_gfp instead of __erofs_get_meta_page.
> That function is a whole lot of duplication of functionality shared
> by a lot of other file systems.
OK, I have to admit, that code was originally just copied from f2fs
with some modification (maybe it's not a good example for us).
Thanks,
Gao Xiang
_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
