>>>>> "Hannes" == Hannes Reinecke <hare@xxxxxxx> writes: Hannes, Hannes> As there is no user (apart from oracleasm) no-one can attach Hannes> protection information to any data, so even the most dedicated Hannes> admin cannot exercise this path, let alone find issues here. That's not how it works! If the filesystem has not attached protection information to a bio the block layer will do it for you. The block layer generates protection information for writes and verifies it for reads. That's how it's worked since day one. The code is there, it is used by everyone with a DIX-capable HBA. See Documentation/block/data-integrity.txt. Normal applications do not want to have to deal with generating protection information, using an async I/O model, keeping completion state around for extended periods of time to figure out whether the I/O actually completed or not and so on. So the kernel-to-platter protection scheme we have in place now is good enough. That doesn't mean that I'm not interested in augmenting libaio. I am. Very. And I know of several applications that are keen to use it. But getting page cache passthrough and filesystem interaction working is non-trivial. That's what has inhibited progress, not extending the libaio API. Hannes> Doug Gilbert and I are currently discussing LID4 / ROD Token Hannes> copy for sg3_utils and the block layer, so any patches would be Hannes> very helpful here. I'm only doing LID1 right now. Any particular reason you are exploring LID4 and ROD? I resumed my efforts before Christmas but I keep running into issues. I'm guessing I'm a week or two from having something that is suitable for consumption. -- Martin K. Petersen Oracle Linux Engineering -- 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
