On Wed, Apr 6, 2016 at 8:59 AM, Shaohua Li <s...@fb.com> wrote: > On Tue, Apr 05, 2016 at 04:45:55PM -0800, Kent Overstreet wrote: >> On Tue, Apr 05, 2016 at 05:41:47PM -0700, Shaohua Li wrote: >> > On Tue, Apr 05, 2016 at 04:36:04PM -0800, Kent Overstreet wrote: >> > > On Tue, Apr 05, 2016 at 05:30:07PM -0700, Shaohua Li wrote: >> > > > this one: >> > > > http://marc.info/?l=linux-kernel&m=145926976808760&w=2 >> > > >> > > Ah. that patch won't actually fix the bug, since md isn't using >> > > blk_default_limits, it's using blk_set_stacking_limits(). >> > >> > Not really, the limit is set by under layer disk not md, otherwise it >> > should be BLK_SAFE_MAX_SECTORS, but the reported bio has 2560 sectors. >> > blk_set_stacking_limits() will use it. >> >> What? Well, that could should just be deleted, there's no reason anymore for >> md >> to care about the queue limits of the devices underneath it. >> >> Regardless, using BLK_DEF_MAX_SECTORS to limit # of pages in the biovec is >> _crazy_. Why would you even do that? We have a separate field in queue limits >> for # max segments, use it. > > We don't limit the max segments in blk_queue_max_segments(), but we can > add. On the other hand, limit max segments to 256 could be a problem, > because bvec page isn't always 4k, this might make some bio smaller.
It is nothing with max segments limit, it is about max sectors limit: think about one big bio which includes 2Mbytes, then 512 bvecs are required, but the 2M buffer can be continuous physically. > -- > To unsubscribe from this list: send the line "unsubscribe linux-block" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html
