>From: "Tom Buskey" <[EMAIL PROTECTED]>
>Date: Thu, 04 Apr 2002 13:27:31 -0500
>
>Bayard Coolidge USG said:
>>
>>>Take a PC & install a minimal Linux or *BSD on it.
>>>Install multiple IDE disks.
>>>Run software RAID on it
>>>Install a SCSI card in it.
>>>
>>>Now, connect via SCSI to another machine (that doesn't have IDE) & use
>>>it as an external RAID system.
>>
>>Well, as others have pointed out, using Target Mode is the way to go
>>if you *insist* on doing it this way. However, I can tell you from
>>personal professional experience, it ain't easy. What SCSI Host Bus
>>Adapters are you planning to use and does their firmware "know"
>>Target Mode? (Consider that a rhetorical question, BTW). How do you
>>(plan to) turn on Target Mode support in your SCSI Driver or your
>>HBA's device driver? (Assuming you know how, or it's documented...)
>
>I'm not saying this is a good idea for a production environment.  As I 
>said in another post, I've seen something about FreeBSD being able to 
>do this, but I haven't been able to find it.

I tested custom devices like this from EMC.  I agree that it could be
a usefull thing, and that it should work in theory.  I think the big
current limitation is that linux doesn't know how to act as a target.
As far as I know there really isn't any difference in being a host or
target it's just what role your system takes when probbed. 

My guess is that the BSD software to do this either, is a kernel
module or takes over the SCSI device and handles all the requests "as
a target".  That would be the hard part.  From their it should be very
easy, SCSI devices are linear, like a large array of blocks.  You just
need a mapping from the target storage device your pretending to be to
the real data and hand it back.  You could cheat and use Linux RAID
software on a filesystem or do the raid yourself to the raw disk space
on the linux box.

>>>>> I also don't want the traffic to go across the net.
>>
>>What net? If you have dedicated Ethernet adapters on each system and
>>use a crossover cable between them, it's not an issue.
>
>True.  But then you're doing network access instead of SCSI access.

It would be hard to verify but I'm guess you could get almost as much
bandwith out of a GIGABIT network as you would over the SCSI.  And
that code has been looked over more than your SCSI targeting solution
would be.

Although there should be better protocols than NFS.  I know there are
ones coming that will be much better!

>>>>> SCSI is *much* faster then ethernet.
>>
>>I agree with  Mark Komarinski's assessment. Running 100 Mbit/sec FDX
>>should do the trick for you. Remember, you'll have some track/sector
>>seek times, so it's unlikely, in a TP environment, that you'll max out
>>the link for very long.
>
>Yep.  100Mb ~ 10MB (roughly).  There's also some latency from software 
>RAID.
>
>I'm also not interested in creating a Network Appliance type box.

Keep in mind that they are normally doing this over the network.  They
also write their own network stack that cheats where possible to keep
the latency time way down on writes.

They are who you might want to watch for the newer NFS protocols that
are coming.  I think you'll find they will be open standards as well.

>>And, since you're running a database, you want to make sure your data
>
>I'm not. I'm just putting forth an example of where an NFS'd filesystem 
>doesn't work as well as a local filesystem.
>
>>transfers are reliable. Running with hacked-up SCSI HBA firmware and
>>device drivers is not, IMNSHO, commensurate with that...
>
>True.

Actually that's why I'm not really a fan of ANY software raid
solution.  If you try to define "hacked-up" you'll see there's a fine
line between "product" and "hack".

--------------------------------------------------------------
 Robert E. Anderson                     email: [EMAIL PROTECTED]
 Systems Programmer                     phone: (603) 862-3489
 UNH Research Computing Center            fax: (603) 862-1761
--------------------------------------------------------------

*****************************************************************
To unsubscribe from this list, send mail to [EMAIL PROTECTED]
with the text 'unsubscribe gnhlug' in the message body.
*****************************************************************

Reply via email to