On 07/15/2010 10:03 AM, Martin K. Petersen wrote: >>>>>> "Christof" == Christof Schmitt <christof.schmitt@xxxxxxxxxx> writes: > > Christof> While experimenting with the data integrity support in the > Christof> Linux kernel, i found that the block layer integrity code can > Christof> send integrity data segments for a request that do not adhere > Christof> to the queue limits. The integrity data segment can be larger > Christof> than queue_max_segment_size and the segment does not adhere to > Christof> the queue_segment_boundary. > > Correct. That was a deliberate design decision. > > Modern HBAs allow essentially indefinite chaining and our block layer > segmentation controls are to some extent legacy baggage. I did not want > to put in a set of constraints on the DI scatterlist because I was > afraid it would encourage vendors to actually them. That sounds like a very batch design decision. Either the limits are explicitly given and different, or if not we have to assume that they are the same as the data limits at least. So do they have limits or not? Essentially indefinite, what does that mean? If they are limited, then we must have settings to cope and map around those. If these limits are not the same as the regular data limits, then those limits could be separate. > Christof> It appears to me that the right way would be to apply the same > Christof> restrictions that are in place for data segments also to > Christof> integrity data segments. The patch works for my experiments > Christof> and applies on top of the current Linux tree (2.6.35-rc5). > > Who says constraints on the integrity scatterlist are the same as on the > data ditto? In my experience they are not. If you must do this, then > the DI constraints should be separate from the data segmentation ones. > But I'm interested in what motivated this change to begin with. Yes me too, what bug triggered this patch? -- 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
