Vladislav Bolkhovitin wrote:
James Bottomley wrote:
On Fri, 2005-12-09 at 18:29 +0300, Vladislav Bolkhovitin wrote:
Additionally, it's perfectly possible for all of this to be done zero
copy on the data. A user space target mmaps the data on its storage
device and then does a SG_IO type scatter gather user virtual region
pass to the underlying target infrastructure. We already have this
demonstrated in the SG_IO path, someone just needs to come up with the
correct implementation for a target path.
I'm not completely understand how it will work. Consider, there are
READ/WRITE commands with random data sizes arrive from an initiator.
Are you going to do map/unmap for each command individually or alloc
data buffers for commands from a premapped area and live with
possible its fragmentation? If map/unmap individually, then I should
say that those are very expensive operations.
You do it the same way an array does: the model for SPI is read command
phase, disconnect, process command (i.e. set up areas) reconnect for
data transfer.
map/unmap are really only necessary if you're emulating the data store,
but it's a fairly cheap operation on linux: it just causes the creation
of a vm_area. If it's a pass through, you can use SG_IO to pull it in
and the SG_IO like output to shoot it out again, effectively using a
piece of user memory as a zero copy buffer.
Fragmentation isn't an issue because the I/O goes via sg lists , all
that's needed is a bunch of pages.
OK, I see what you meant, thanks.
I do have to say that I consider operation in interrupt context (or even
kernel context) to be a disadvantage. Compared with the response times
that most arrays have to SCSI commands, the kernel context switch time
isn't that significant.
Are you sure that there are no now or will be available in the nearest
feature such (eg iSCSI) SCSI arrays with response time/latency so small
that having 5 (five) context switches or more per command, some of which
include map/unmap operations, will not increase the latency too much? I
mean, eg NFS server, which originally was user space daemon and many
people didn't want it in the kernel. Eventually, it's in. I don't see
any fundamental difference between NFS server and SCSI target server,
Isn't the reason a NFS server is still in the kernel is becuase some of
the locking difficulties?
-
: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
