[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]
Re: [dm-devel] [PATCH 2/5] virtio_blk: implement REQ_FLUSH/FUA support
- From: Tejun Heo <tj kernel org>
- To: Christoph Hellwig <hch lst de>
- Cc: tytso mit edu, linux-scsi vger kernel org, mst redhat com, jaxboe fusionio com, jack suse cz, rusty rustcorp com au, linux-kernel vger kernel org, linux-raid vger kernel org, linux-ide vger kernel org, dm-devel redhat com, James Bottomley suse de, konishi ryusuke lab ntt co jp, linux-fsdevel vger kernel org, vst vlnb net, rwheeler redhat com, swhiteho redhat com, chris mason oracle com
- Subject: Re: [dm-devel] [PATCH 2/5] virtio_blk: implement REQ_FLUSH/FUA support
- Date: Tue, 17 Aug 2010 18:22:38 +0200
Hello,
On 08/17/2010 03:23 PM, Christoph Hellwig wrote:
>> 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).
Right.
> 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.
Hmmm... yeah, we can drop it. Michael, what do you think?
Thanks.
--
tejun
[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]