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

[Ming Zhang]

On Mon, 2007-01-22 at 15:39 +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 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.
> 

thanks a lot!

> 
> - 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.
-- 
http://blackmagic02881.wordpress.com/