lkml.org 
[lkml]   [1999]   [May]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: host (multibus) failover
Chris Smith wrote:
>
> Hi,
>
> Okay, I just looked everywhere I could think of and didn't see anything
> mentioned about support in Linux for a multibus failover configuration.
> Basically, a disk would be accessible on several host adapters (SCSI
> adapters, whatever) and can be accessed through whichever ones work. This
> technique is used in (at least) VMS and NT to get more redundancy in
> several high-end storage systems, Digital StorageWorks being the one I know
> about. I'm interested in implementing this for Linux, but a few questions
> first.
>
> 1. Is this done? Did I miss it somewhere? I'd hate to duplicate someone's
> work.
>
Well, sort of. Although it's not exactly what you are proposing, the
software RAID-1 stuff can achieve the same thing. You just do a RAID-1
on two identical disks on diferent SCSI busses. AFAIK the RAID-1 code
can handle a single failing disk.

Of course, this requires two disks instead of just one. As a quick
aside, how do you get one disk onto two SCSI busses?

> 2. I'm planning on adding some sort of new virtual block device on a new
> major number that can be associated with a list of physical block devices
> via (ioctl / proc filesystem) and forwards all access requests to the
> currently preferred path. A failure would simply cause the next available
> path to become preferred. This looks like it'll work okay. Anyone see
> problems with this approach, or a better way?
>
Dunno. The Linux SCSI layer can be picky; I've had my 2.2.x all-SCSI
system freeze completely when I try to use a Jaz cartridge with bad
blocks on the same SCSI bus as my data drives. Assuming the SCSI layer
works well, you should have no problems.

You might want to hack things a bit, so instead of retrying a failed
command N many times, after the first (second, whatever) failure, it
automagically aborts that one, and changes the preferred path. Or maybe
it just takes the failed SCSI command and forwards it to the next host.

> 3. Anyone have hardware that they can test this on? I don't, so if you do
> and care about this, let me know. I'll e-mail you when I have something to
> test.
>
It really depends on what kind of hardware is required.

> I'd like to emphasize that this isn't gonna be done some time soon. I'm
> just getting started with kernel hacking, and this just looked like
> something cool to work on that actually has a point. If people are really
> interested I'll try to get it done, but no guarantees.
>
> Thanks,
>
> Chris Smith <cd_smith@ou.edu>
>
> PS: Please CC replies if convenient -- I'm subscribed to the list digest,
> but I'll see direct mail a lot sooner.
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.rutgers.edu
> Please read the FAQ at http://www.tux.org/lkml/

--
.-------------------------------------------------------------------------
| Ian Eure <ieure@crosssound.narrows.com>
| Network Administrator, Cross Sound Appraisal Company
|
| "A conclusion is simply the place where someone got tired of
thinking."

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:51    [W:0.072 / U:0.028 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site