On Tue, Aug 17, 2010 at 10:17:15AM +0200, Tejun Heo wrote: > >> Remove now unused REQ_HARDBARRIER support and implement REQ_FLUSH/FUA > >> support instead. A new feature flag VIRTIO_BLK_F_FUA is added to > >> indicate the support for FUA. > > > > I'm not sure it's worth it. The pure REQ_FLUSH path works not and is > > well tested with kvm/qemu. We can still easily add a FUA bit, and > > even a pre-flush bit if the protocol roundtrips matter in real life > > benchmarking. > > Hmmm... the underlying storage could be md/dm RAIDs in which case FUA > should be cheaper than FLUSH. If someone ever wrote a virtio-blk backend that sits directly ontop of the Linux block layer that would be true. Of the five known virtio-blk backends all operate on normal files using the Posix I/O APIs, or the Linux aio API (optionally in qemu) or in-kernel vfs_read/vfs_write (vhost-blk). Given how little testing lguest gets compared to qemu I really don't want a protocol addition for it unless it really buys us something. Once we're done with this barrier conversion I plan into benchmarking FUA and a pre-flush tag on the command for virtio in real life setups, and see if it actually buys us anything. -- 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
