On Mon, Apr 22, 2002 at 08:06:47AM +0100, arjan@fenrus.demon.nl wrote:
> In article <3CC3B2AA.80217EA0@in.ibm.com> you wrote:
>
> > or maybe have a way pass back an error to retry with smaller size.
> > Maybe 2 limits (one that indicates that anything bigger than this is
> > sure to
> > get split, so always break it up, and another that says that anything
> > smaller
> > than this is sure not to be split, so use this size when you can't
> > afford a
> > split).
>
> Unfortionatly it's not always size that's the issue. For example in my
> code I need to split when a request crosses a certain boundary, and without
> going into too much detail, that boundary is 62 Kb aligned, not 64
> (for technical reasons ;().
Yes, I know .. Size alone isn't the only constraint - this was what
the earlier grow_bio discussion (about max BIO sizes) was all
about. Actually, not only that, in cases where the queue already has
requests which we can merge, even the size the decision gets more complex ...
That's why allowing for the exception cases when we do need to split
seemed like an option to take.
>
> Size won't catch this and while a 64Kb Kb block will always be split, that
> you can be sure of, even a 4Kb request, if unlucky, can have the need to
> split up.
>
This would as you observe be caught in alignment checks. The limit
doesn't have to be a fixed size (e.g function of block) or even size
only thing. Conceptually the question is if it can be generalized into
a compound worst case constraint through layers of lvm et al (at bind
time). It could be expressed as multiple checks.
Regards
Suparna
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Apr 23 2002 - 22:00:30 EST