From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 9 16:38:53 2006 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DC2D116A422; Thu, 9 Mar 2006 16:38:53 +0000 (GMT) (envelope-from nate@root.org) Received: from ylpvm12.prodigy.net (ylpvm12-ext.prodigy.net [207.115.57.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6908B43D45; Thu, 9 Mar 2006 16:38:53 +0000 (GMT) (envelope-from nate@root.org) Received: from pimout6-ext.prodigy.net (pimout6-int.prodigy.net [207.115.4.22]) by ylpvm12.prodigy.net (8.12.10 outbound/8.12.10) with ESMTP id k29GclbL020399; Thu, 9 Mar 2006 11:38:48 -0500 X-ORBL: [71.139.114.10] Received: from [10.0.5.50] (ppp-71-139-114-10.dsl.snfc21.pacbell.net [71.139.114.10]) by pimout6-ext.prodigy.net (8.13.4 outbound domainkey aix/8.13.4) with ESMTP id k29GciCs134352; Thu, 9 Mar 2006 11:38:49 -0500 Message-ID: <44105A01.5080309@root.org> Date: Thu, 09 Mar 2006 08:38:25 -0800 From: Nate Lawson User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Eric Anderson References: <4395BF04.50101@centtech.com> <43960F55.3010508@root.org> <43975926.1010302@centtech.com> <43975F5F.5080901@samsco.org> <439782AA.6000408@root.org> <4397B731.6010308@centtech.com> <4397B82C.5020004@samsco.org> <4397EBC7.9030105@root.org> <440F5141.7010002@centtech.com> In-Reply-To: <440F5141.7010002@centtech.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 09 Mar 2006 16:47:53 +0000 Cc: freebsd-scsi@freebsd.org Subject: Re: scsi-target and the buffer cache X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2006 16:38:54 -0000 [mailing list changed to scsi@] Eric Anderson wrote: > 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. hints aren't needed. Here's an intro on how to use it: http://root.org/~nate/freebsd/scsi/README.targ The same card is in target or initiator mode based on the scsi_target user program. When it's running, target mode is enabled. > 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. There was some debate when I imported it whether to make it an example or usr.sbin. Given the lack of updates (i.e. ki_sig or whatever), I probably should have put it somewhere else. -- Nate