On 01/07/2014 10:43 PM, Martin K. Petersen wrote: >>>>>> "Hannes" == Hannes Reinecke <hare@xxxxxxx> writes: > > Hannes> Plus (as hch rightly pointed out) as there is no defined > Hannes> userland interface the question is why we bother with all the > Hannes> DIX stuff in the block layer. > > Because it catches problems in the path between block layer and HBA > ASIC? FWIW, we find more issues there than we do between initiator and > target. > But how should it do that exactly? As there is no user (apart from oracleasm) no-one can attach protection information to any data, so even the most dedicated admin cannot exercise this path, let alone find issues here. > API issues aside, another reason adoption has been slow is that very few > applications truly care about this stuff. The current approach in which > data is protected when the I/O is submitted by the filesystem is good > enough for most things. Saves the filesystem people the trouble of > dealing with it too. > > In reality there are only a handful of applications that would actually > benefit from an explicit userland API. Mostly in the database > department. All the potential consumers of an interface I talked to > wanted to use aio so that's why we've focused our efforts there. > aio is perfectly fine; all I care is to have _any_ way of feeding protection information into the kernel. > Both Darrick and I have been busy with other projects the last little > while. I'll start looking at this again when I'm done with copy > offload... > Speaking of which, are there any patches? Doug Gilbert and I are currently discussing LID4 / ROD Token copy for sg3_utils and the block layer, so any patches would be very helpful here. Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage hare@xxxxxxx +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) -- 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
