Date: Wed, 29 Nov 2000 12:30:57 -0800 (PST) From: Matthew Jacob <mjacob@feral.com> To: Nat Lanza <magus@cs.cmu.edu> Cc: Tom Samplonius <tom@sdf.com>, Chuck McCrobie <mccrobi@aplcenMP.apl.jhu.edu>, freebsd-scsi@FreeBSD.ORG Subject: Re: RFC 2143 (IP over SCSI) Support in FreeBSD Message-ID: <Pine.LNX.4.21.0011291221080.1337-100000@zeppo.feral.com> In-Reply-To: <uocwvdmy1ma.fsf@hurlame.pdl.cs.cmu.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On 29 Nov 2000, Nat Lanza wrote: > Matthew Jacob <mjacob@feral.com> writes: > > > Yes and no. The ANSI SCSI-2 spec took years to finalize. Same for SCSI-3. If > > it's a worthwhile feature, and you're dealing just with the software > > instantiation, it might be worth looking at doing for early releases. > > iSCSI has a much more limited scope than the T10 work; one of the > major goals is to get something working and standardized quickly. > > But yes, there is the possibility of the standardization process > taking a long time. > > Even so, I'd much rather see an effort to implement iSCSI based on the > draft IETF documents than one to implement some vendor's incompatible > thing. Of course. Implementing some vendor solution is pointless unless you're the vendor. FreeBSD is not the vendor. Ergo, FreeBSD will not implement some vendor solution. As a corollary, FreeBSD is also not pointless. Now, is that a perfect compound negative syllogism, or what? :-) > > > > Our lab is working on SCSI-over-IP, and our target platforms are FreeBSD > > > and Linux. We would most likely be interested in contributing our code to > > > the FreeBSD community when we're done, but it's far too early to make any > > > promises. > > > > Can you keep us posted on this? We'd absolutely love it if CMU (d'ya > > work with Garth?) did this. > > Sure. > > Also, yes, I do work with Garth. He's no longer the director of the > Parallel Data Lab now that he's working on his startup, though. These > days the lab's headed by Dave Nagle, who's really more involved in the > iSCSI stuff. > > > Ah. Cool. Is this available to be looked at? Define 'decent'... > > It's not available yet, but I hope it will be before too long. Our > lab's industry sponsorship obligations and the time constraints of > paper deadlines limit when and how we can publically release code, > unfortunately. > > A simple (~1500 line) server using the Linux SCSI generic layer to > talk to a Quantum Atlas 10K can pull sequential read/write data over a > Myrinet link at media speeds (25MB/sec or so), and one using a SCSI > ramdisk as backing store can do at least 35-40MB/sec over Myrinet. We > see slightly lower performance over gigabit ether, but we haven't > spent too much time optimizing gigabit performance. > > This is with a simple userlevel server and kernel-level client, and no > unusual hardware (well, other than the Myrinet, I guess) -- the > machines involved are generic PII boxes, and we're using standard > unmodified TCP and SCSI. Huh- what was the CPU utilization? I suspect higher than native, but CPU speed arguments are more or less now like what memory utilization arguments were ten years ago (obsoleted by having enough- i.e., requiring lots of memory or CPU isn't a problem if it's cheaply available). Still, that sounds to me like the concept is proved. Depending on whether or not the FC switch vendors can get out there with 10Gb switches before the Gb ethernet switch vendors will define whether FC dies in 3 years or in 6 years. Tsk- too bad- I've put a lot of effort in so far. Well, we'll see whether the s/w portions of Fibre Channel (e.g., the SAN domain stuff) gets to be usable within IP over SCSI. -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.4.21.0011291221080.1337-100000>