On 2010-11-25 17:35, Martin K. Petersen wrote:
>
> When stacking devices a request_queue is not always available. This
> forced us to have a no_cluster flag in the queue_limits that could be
> used as a carrier until the request_queue had been set up for a
> metadevice.
>
> There were several problems with that approach. First of all it was up
> to the stacking device to remember to set queue flag after stacking had
> completed. Also, the queue flag and the queue limits had to be kept in
> sync at all times. We got that wrong, which could lead to us issuing
> commands that went beyond the max scatterlist limit set by the driver.
>
> The proper fix is to avoid having two flags for tracking the same thing.
> We deprecate QUEUE_FLAG_CLUSTER and use the queue limit directly in the
> block layer merging functions. The queue_limit 'no_cluster' is turned
> into 'cluster' to avoid double negatives and to ease stacking.
> Clustering defaults to being enabled as before. The queue flag logic is
> removed from the stacking function, and explicitly setting the cluster
> flag is no longer necessary in DM and MD.
Great, the two different values and needing to sync them was horrible.
What kind of testing did you do? Have to be a little extra careful at
this point.
> @@ -87,7 +87,7 @@ EXPORT_SYMBOL(blk_recount_segments);
> static int blk_phys_contig_segment(struct request_queue *q, struct bio *bio,
> struct bio *nxt)
> {
> - if (!test_bit(QUEUE_FLAG_CLUSTER, &q->queue_flags))
> + if (blk_queue_cluster(q))
> return 0;
Oops, inverted this one.
--
Jens Axboe
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
