[Stgt-devel] sg_turs on stgt iscsi drive is very slow

[FUJITA Tomonori]

From: Ming Zhang <blackmagic02881 at gmail.com>
Subject: Re: [Stgt-devel] sg_turs on stgt iscsi drive is very slow
Date: Sat, 20 Jan 2007 11:08:00 -0500

> On Sun, 2007-01-21 at 01:05 +0900, FUJITA Tomonori wrote:
> > From: Ming Zhang <blackmagic02881 at gmail.com>
> > Subject: Re: [Stgt-devel] sg_turs on stgt iscsi drive is very slow
> > Date: Sat, 20 Jan 2007 10:52:42 -0500
> > 
> > > > > do you have a road map for stgt? see, need to read your reply for Pete
> > > > > to know OSD is already under your plan.
> > > > 
> > > > Well, I decided not to plan anything. I was supposed to finish iSER
> > > > target code however I'm playing with other stuff like sg v4.
> > > 
> > > this does not do good for stgt project in long term. u can always lay it
> > > out and people know how to contribute more efficiently.
> > 
> > I can't say when something will be implemented. But I said what the
> > project needs (and what I want to do). So I think that people know how
> > to contribute.
> 
> sure. maybe i missed some email traffic here, then could u have wish
> list here? thanks.

Here's something that I think about. Mike also has some different
ideas, I think.


- FC target mode drivers

First, we need to figure out how to add target mode support to
mainline scsi_transport_fc. Then we need more tweaks in the user-space
code.


- user-space passthrough

sg v4 is necessary for the user-space target drivers' passthrough.


- AIO event notification

The user-space target drivers (only iSCSI now, possibly SRP later on)
need the event notification to handle both synchronous and
asynchronous file descriptors. We use the aio epoll patch (that would
be merged into mainline at 2.6.21), but it's not effective. We need
something like kevent.


- backing-storage disk images

bd_mmap/aio support only raw images. They should support fancy disk
images (like QCOW, vmdk, etc) to enjoy snapshot without using LVM.
Adding QCOW to bd_mmap is quite simple, but a bit tricky to bd_aio
(see Xen's blktap code). Without code duplication, we need to add disk
images to both bd_mmap/aio.


- rearrange backing storage code

Now the backing storage code includes: file I/O (bd_mmap/aio/xen) and
user-space passthrough (bd_sg). The design are hacky. The backing
storage code will be more complicated (supports the fancy disk images,
OSD, etc). We need to reconsider the design at some future time.


- kernel-space passthrough

We need a new kernel module for the kernel-space target drivers'
passthrough. Seems it's ok by James as long as it's cleanly
implemented.


- persistent reservations

Nice though I'm not sure this is that important.


- backing-storage virtualization

Virtual tape support would be nice but it needs lot of work and I have
no plan to implement this.

Virtual cdrom support isn't difficult but I'm not sure people really
need it.