From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 8 21:49:02 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 3831416A420 for ; Wed, 8 Mar 2006 21:49:02 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from mh2.centtech.com (moat3.centtech.com [207.200.51.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9605B43D45 for ; Wed, 8 Mar 2006 21:49:01 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from [10.177.171.220] (neutrino.centtech.com [10.177.171.220]) by mh2.centtech.com (8.13.1/8.13.1) with ESMTP id k28Lmqrv020274; Wed, 8 Mar 2006 15:48:53 -0600 (CST) (envelope-from anderson@centtech.com) Message-ID: <440F5141.7010002@centtech.com> Date: Wed, 08 Mar 2006 15:48:49 -0600 From: Eric Anderson User-Agent: Thunderbird 1.5 (X11/20060112) MIME-Version: 1.0 To: Nate Lawson 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> In-Reply-To: <4397EBC7.9030105@root.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.87.1/1318/Tue Mar 7 14:55:18 2006 on mh2.centtech.com X-Virus-Status: Clean Cc: Scott Long , hackers@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: Wed, 08 Mar 2006 21:49:02 -0000 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. ------------------------------------------------------------------------