>>>>> "Jens" == Jens Axboe <axboe@xxxxxxxxx> writes: Jens, >> It is a requirement for SG_IO, firmware updates, tape drives, >> etc. that the controller limits are reported correctly since they do >> I/Os that are much bigger than typical filesystem requests. When we >> tried to conflate the two things broke in interesting ways. Jens> That's crazy. If max_hw_sectors_kb is expected to be the DMA Jens> constraint, then it makes no sense to name it 'sectors'. I don't believe I named it :) It's the maximum DMA transfer size supported by the controller. Some controllers have limitations above and beyond their scatter-gather capabilities. You could argue that they should use max_dev_sectors since the limit is probably more of a firmware virtual disk thing than a DMA engine constraint. But max_dev_sectors and the matching SCSI transfer size cap are both very new to the game. Jens> We currently have the one exported constraints, and making it Jens> anything but the 'this is the maximum IO size we can support' Jens> would be nonsensical. That implies that the value is the same for all types of I/O which is not the case. Hasn't been for a long time. See discard, write same, etc. blk_rq_get_max_sectors() is passed a struct request because the answer depends on what type of request and which operation it is. With max_hw_sectors_kb we're not so lucky. We could assume read/write but it would break existing apps that check it for SG_IO or to set tape block size. And they do exist. Jens> Which, coincidentally, is what that file already is for most other Jens> devices. Because none of the other protocols happen to have device limits. Jens> It'd make more sense to bring SCSI into this realm, instead of Jens> imposing this weird world view on others. Hey, I didn't invent the SCSI device constraint. I think it sucks. But it is a hard limit and we absolutely have to enforce it. And we can't lower the hw limit willy-nilly because it breaks non-REQ_TYPE_FS requests. As a result, max_dev_sectors is only used by sd and it's only used to gate max_sectors_kb for filesystem requests. I would have happily kept it internal to SCSI but users need to be able to set max_sectors_kb through sysfs. And consequently I need to be able to clamp on it there. I'm happy to clean things up if you have a better idea how to enforce the device limit without breaking existing apps. It's possible that with the arbitrary bio size changes some of the original pain points have gone away. Will take a look. But implementation aesthetics aside, Andy's problem still persists. Because at least in the context of SCSI the answer to his question is "it depends" :( -- Martin K. Petersen Oracle Linux Engineering -- To unsubscribe from this list: send the line "unsubscribe linux-block" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
