*why* is it interesting to allow kernel code to submit aio requests, and loop devices to be able to direct I/O requests all the way to the underlying file systems.
As I understood it, lo those years ago, the use case was virtual guests provisioned on loopback devices on files in the host file system. In this use case either having loop implement a second writeback cache or having it only capable of one sync IO in flight at a time is pretty bad when you're trying to offer consistent and performant file systems to the guest. I believe one motivations for using loopback files is the ability to use ocfs2's reflinks to get cluster-wide cow snapshoting of guest file systems in files in ocfs2. But I'll let Dave (or Chris?) share more about how this stuff is actually used. Really, if we had our way, file systems would offer the bio submission and completion interface for file data. Then loopback dev IO <-> file system IO would be trivial. The aio+dio iocbs are an existing aproximation :/. - z -- 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
