WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] Re: More virtio users

On Tue, Jun 12 2007, Rusty Russell wrote:
> On Tue, 2007-06-12 at 08:24 +0200, Jens Axboe wrote:
> > On Tue, Jun 12 2007, Rusty Russell wrote:
> > > On Mon, 2007-06-11 at 09:33 +0200, Jens Axboe wrote:
> > > > The other main request type is blk_pc_request(). In the data setup it's
> > > > indentical to blk_fs_request(), there's a bio chain off ->bio. It's a
> > > > byte granularity entity though, so you should check ->data_len for the
> > > > size of it. ->cmd[] holds a SCSI cdb, which is the command you are
> > > > supposed to handle.
> > > 
> > > SCSI?  I'm even more lost now.
> > > 
> > > Q: So what *are* the commands?
> > 
> > They are SCSI commands!
> > 
> > > Q: Who puts them in my queue?
> > 
> > If you want to support SG_IO for instance, you'd have to deal with SCSI
> > commands.
> 
> I do not.  If someone wants to implement a SCSI layer over virtio, I
> think that's wonderful.  Fortunately, that's not the problem I'm trying
> to solve.

Then you can blissfully ignore blk_pc_request() and just keep your
current code for rejecting !blk_fs_request().

> > -o barrier=1 for ext3, it doesn't use barriers by default.
> 
> That's, um, a little disturbing.
> 
> But, it works.  Thanks!

Well, feel free to send a patch making barrier=1 the default, then I'll
make sure that mails from users that are confused because performance is
suddenly much worse get redirected to you :-)

Kudos to XFS for making it the default, though!

-- 
Jens Axboe


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel