Nate Lawson wrote:
Scott Long wrote:
Eric Anderson wrote:
Nate Lawson wrote:
Agree 100%. While having it in usermode means there are boundary
crossings that increase per-transaction latency, the actual bulk
data transfer is via zero-copy IO and you should be able to exceed
the data transfer rates of several 10K RPM drives on decent hardware.
Ok, great.. Now, will scsi_target work ok with raw devices, or only
files? (although I'm not sure theres all that much difference really).
You can write your userland code to use whatever files or devices you
want. Are you talking about the scs_target.c code in
/usr/share/examples? That's just a skeletal example that you can use
as a starting point for your own work.
No, it's not just a skeletal example. You can point it at a raw
device as the backing store file and it will work as a block device
(i.e. RBC command set). It has been tested as working at least
moderately fast over SCSI, FC, and firewire.
I'm finally getting around to playing with this, and I'm having some
problems. First, I can't seem to make one isp card in target mode and
the other an initiator. I've messed with adding the following to
loader.conf:
hint.isp.0.role="initiator"
hint.isp.1.role="target"
that still doesn't show my currently connected fiber channel devices on
the initiator side.
I've tried a few different kernel options, currently I have:
options ISP_TARGET_MODE=1
device targ
I've also tried just:
options ISP_TARGET_MODE
and that doesn't seem to allow me to select one either.
Anyhow, I've compiled scsi_target (from
/usr/share/examples/scsi_target), and tried to run it using a 20gb file
as the target, and still I can't seem to get it working.
Is there a doc somewhere I need to read?
Also - as a side note, the Makefile for scsi_target seems like it's
missing a path variable in order to do a make install, but that's not a
real issue.
Thanks!
Eric
--
------------------------------------------------------------------------
Eric Anderson Sr. Systems Administrator Centaur Technology
Anything that works is better than anything that doesn't.
------------------------------------------------------------------------
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
