On Tuesday February 6, [EMAIL PROTECTED] wrote: > On Wed, 7 Feb 2007 10:26:56 +1100 > Neil Brown <[EMAIL PROTECTED]> wrote: > > > +static int bio_fits_rdev(struct bio *bi) > > +{ > > + request_queue_t *q = bdev_get_queue(bi->bi_bdev); > > + > > + if ((bi->bi_size>>9) > q->max_sectors) > > + return 0; > > + blk_recount_segments(q, bi); > > + if (bi->bi_phys_segments > q->max_phys_segments || > > + bi->bi_hw_segments > q->max_hw_segments) > > + return 0; > > + > > + if (q->merge_bvec_fn) > > + /* it's too hard to apply the merge_bvec_fn at this stage, > > + * just just give up > > + */ > > + return 0; > > + > > + return 1; > > +} > > Isn't think going to return 0 rather a lot of the time?
Why do you say that? merge_bvec_fn is only set for dm, md, pktcdvd.c so what won't cause a zero in real-world cases (it rarely makes sense to put a raid5 on top of those things). So it will only return zero when ->max_sectors or ->max_*_segments are less than the default, and while there are certainly quite a few of those I wouldn't have expected them to be a majority (else we would have had more complaints from -mm testers). Yes, we should find the minimum of those values for devices currently in the array and use that information in raid5's merge_bvec_fn to stop bios growing too large. That would make it return 0 somewhat less often. But I think for a lot of modern hardware, it won't return 0 at all.... or am I just not seeing some really obvious typo that you can see ?? NeilBrown - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/