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 ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
