On Wed, Mar 30, 2016 at 09:50:30AM -0700, Shaohua Li wrote:
> > bcache should be fixed to not allocate larger than allowed bios then.
> > And handling too large arguments to bio_alloc_bioset is still useful to
> > avoid the checks in the callers and make it robust.
>
> Doesn't this conflict the goal of arbitrary bio size?
I don't think we ever had the goal of entirely arbitrary bio sizes,
we wanted to get rid of the driver imposed limits. And I/O submitter
deciding that it's not bound by BIO_MAX_PAGES is something entirely
different.
> I think nothing is
> wrong in bcache side. The caller can allocate any size of bio, the block
> layer will split the bio into proper size according to block layer
> limitatio and driver limitation.
If we get actual arbitrary large bios we
a) assume drivers can handle bios larger than BIO_MAX_PAGES, which
we've just noticed md can't
b) have to handle all sorts of mempools to handle this giant size
nothing that can't be be done, but it's pretty obvious that we're not
there yet. And I'm not really sure it's necessarily worth it, but
I'm happy to be proven wrong.
> As long as bio_split can do the right
> job, caller of bio allo is good.
But it's pretty clear that it currently doesn't do the right job,
and reducing general queue limits for a single submitter that doesn't
follow the protocol isn't the way to go. The obvious fix is to
make bcache behave like everyone else for now, and then look into
how useful and painful it would be to move to larger bios in general.
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html