OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

virtio-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [virtio-comment] [PATCH 2/5] virtio-blk spec: writeback cache enable improvements

On Mon, 2013-08-19 at 22:10 +0300, Michael S. Tsirkin wrote:
> On Mon, Aug 19, 2013 at 08:00:27PM +0200, Paolo Bonzini wrote:
> > Il 19/08/2013 18:44, James Bottomley ha scritto:
> > >> And piggybacking on SCSI means that whenever a new feature comes along,
> > >> someone else is already doing the work to integrate into the Linux block
> > >> layer, to use it, to export it to userspace, etc.  This typically
> > >> happens before hosts implement the feature, so us virt people get a
> > >> large part of the work for free; we only need to implement the feature
> > >> in the host, because these feature rarely if ever affect the SCSI RPC
> > >> interface.  Instead, adding the smallest feature to virtio-blk always
> > >> necessitates updates to both the spec and the guest drivers, in addition
> > >> to the VMM (typically QEMU).
> > > 
> > > Spec, possibly, since someone needs to be told about commands added to
> > > block, but it shouldn't need modification of correctly implemented
> > > drivers.  If the encapsulation were done right, the client would just
> > > send the correct commands, so no code growth.
> > 
> > Ah, I see what you mean now.  It's a different channel to describe
> > features.  That would be a virtio-blk v2 basically.  It would have made
> > sense if done in the beginning, but not now.
> It's worth considering. We can deprecate the WCE bit if we want to.
> I don't think that's virtio-blk v2 really.

It doesn't even need to be v2.  You can keep what you've already done,
just add future features compatibly with the underlying protocol.

> > > But this is illustrative of the point.  When the block layer is patched
> > > to add more stuff (which has been happening quite a lot lately), you
> > > have to rev your spec and update all the guest and host drivers.  This
> > > is one of the reasons for the current SCSI architecture model: not to
> > > have to do this.
> > > 
> > >>> For standards purposes, I'm not really sure
> > >>> how to proceed on this but I believe linux will be the only implementor
> > >>> of virtio-blk, right, so it probably doesn't matter.
> > >>
> > >> There are Windows drivers for virtio-blk.
> > > 
> > > Which are thus effectively emulator drivers.
> > 
> > Yes.
> > 
> > But honestly I'm not sure what your point is... I'm submitting this
> > patch at Rusty's request in order to clean up IP issues.  It's already
> > part of the spec, of QEMU, of the guest drivers.  I don't plan on any
> > other feature creep in virtio-blk, or fwiw no one else doesn't.
> > 
> > Paolo
> virtio-blk is widely used. I wouldn't write it off just yet.
> So I think these comments are valuable.
> For example, this made me realize that even when scsi command
> pass-through is enabled, we either take the clue on WCE support from
> host feature bit. This is wrong, isn't it? We really should send scsi
> commands to the device to figure out and set/clear it.

Right:  this illustrates how the incremental addition can be done: do
pass through on the mode sense SCSI uses to decide this and discovery
can proceed normally.  Older virtio says I don't know what you're
talking about and SCSI assumes write through ... the same will work for
all the other features.

> I also note that virtio-blk simply has custom sysfs attributes
> for WCE control and status. Is this normal?
> James, are there tools that send scsi commands to block devices
> to control WCE?

Yes, it's actually very simple

echo "cache type" > /sys/class/scsi_disk/<dev>/cache_type

Assuming the cache type can be changed (not every disk allows this),
then the sd driver will send the mode select to change it.  Note that
this change is volatile:  the disk will revert to default cache type
once the power is removed.  To make it permanent, you need to update the
"saved" mode page using sg_wr_mode --save



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]