>>>>> "Chuck" == Chuck Lever <chuck.lever@xxxxxxxxxx> writes: >> I guess if we couldn't use the page cache, we probably wouldn't >> attempt to use DIF/DIX interface, but will calculate our own >> checksums once we are going to work on the data integrity feature on >> our side. Chuck> This is interesting. I imagine the Linux kernel NFS server will Chuck> have the same issue: it depends on the page cache for good Chuck> performance, and does not, itself, use direct I/O. Just so we're perfectly clear here: There's nothing that prevents you from hanging protection information off of your page private pointer so it can be submitted along with the data. The concern is purely that the filesystem owning the pages need to handle access conflicts (racing DI and non-DI updates) and potentially sub page modifications for small filesystem block sizes. The other problem with buffered I/O is that the notion of "all these pages are belong to us^wone write request" goes out the window. You really need something like aio to be able to be able to get completion status and re-drive the I/O if there's an integrity error. Otherwise you might as well just let the kernel autoprotect the pages from the block layer down (which is what we do now). -- Martin K. Petersen Oracle Linux Engineering -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
