From owner-freebsd-hackers Fri May 29 07:27:05 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA16333 for freebsd-hackers-outgoing; Fri, 29 May 1998 07:27:05 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from att.com (kcgw1.att.com [192.128.133.151]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id HAA16301 for ; Fri, 29 May 1998 07:26:56 -0700 (PDT) (envelope-from sbabkin@dcn.att.com) From: sbabkin@dcn.att.com Received: by kcgw1.att.com; Fri May 29 09:26 CDT 1998 Received: from dcn71.dcn.att.com ([135.44.192.112]) by kcig1.att.att.com (AT&T/GW-1.0) with ESMTP id JAA13450 for ; Fri, 29 May 1998 09:26:25 -0500 (CDT) Received: by dcn71.dcn.att.com with Internet Mail Service (5.0.1458.49) id ; Fri, 29 May 1998 10:32:54 -0400 Message-ID: To: hackers@FreeBSD.ORG Subject: What to do with this thing ?! Date: Fri, 29 May 1998 10:32:50 -0400 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi! I have brought the SCSI-over-FastEthernet project to the working prototype stage. And that brought a big question, what to do with it ? Actually, there are three questions that need further explanation. But first I shall explain the project, its purposes and weaknesses. The idea is to tunnel the SCSI transfers over the FastEthernet thus extending the possible maximal cable length dramatically. The configuration would look like: SCSI Ethernet SCSI (host)====(converter,master)--------(converter,slave)====(disk) any FreeBSD FreeBSD any Using split SCSI transfers and tag queuing allows to make this kind of configuration rather efficient. Why would anyone want an extension of this kind ? There exists a class of paranoia requiring the master and backup servers be located as far from each other as possible to protect from disasters like fire. Sure, the automatic fire fighting systems do exist but would a computer work soon after a freon bath or covered by lots of dust from smoke generators ? The company where I worked earlier was infected by this kind of paranoia and we had to break the high availability cluster to break up the servers. And I know a whole class of companies in Russia to which this paranoia is inherent. A nice solution would be to use configuration like this: SCSI Ethernet SCSI (host)=====(converter)-----(converter)=====(backup host) | | (disks) (disks) mirror 1 mirror 2 thus having the backup host and the second copy of data in a supposedly safe location and electrically disconnected from the master host. Possible variations may include using the slave part of converter as the disk box as well, SCSI ID/LUN translations in converter, striping, load balancing over several Ethernet connections, mirroring done inside the converter and so on. So, about 1.5 years ago I have started this project as commercial with backup solution of converting it to non-commercial :-) Many things occurred since then, there were lots of organizational problems and since I came to US over half a year ago it was in comatose state at all. Recently I bought a computer and finally finished the working prototype. Since the start of project the Fibre Channel technology became reality, absolutely superior to this project, although, may be, a bit more expensive. And I absolutely don't know anything about the typical paranoias in US companies. So, the first question is: does anybody see any commercial perspectives for this project ? May be in the low-end server market ? May be, for non-Unix servers ? If yes, I would like to hear any offers :-) The second question is: does anybody see any usefulness of this project in whole as free software, a FreeBSD-based application ? Can it benefit the FreeBSD project in some way ? The third question is about using parts of this technology in FreeBSD. Such as a generic target SCSI driver, a SCSI disk device emulator that can be useful for SCSI driver debugging, a pseudo-SCSI device that can wrap the commands to some handler, an IP-over-SCSI implementation. The last one may be used, for example, as a very fast 40MB/s or 80MB/s (with Ultra-2 Wide SCSI, peak raw throughput) network for a distributed computing cluster or a kind of a "backplane" for a router based on such a cluster. With two Ultra-2 Wide SCSI buses the raw peak bandwidth of this backplane would be 1.2Gbit/s :-) Does anybody has any ideas or wish lists ? -Sergey Babkin babkin@bellatlantic.net sab123@hotmail.com sbabkin@dcn.att.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message