[4935] in linux-scsi channel archive
Re: dual-attached disk
daemon@ATHENA.MIT.EDU (Stephen C. Tweedie)
Sat Oct 17 13:52:18 1998
Date: Sat, 17 Oct 1998 12:51:01 +0100
From: "Stephen C. Tweedie" <sct@redhat.com>
To: Eric Youngdale <eric@andante.jic.com>
Cc: "Stephen C. Tweedie" <sct@redhat.com>, thoth@purplefrog.com,
linux-scsi@vger.rutgers.edu, "Leonard N. Zubkoff" <lnz@dandelion.com>
In-Reply-To: <Pine.LNX.3.96.981016222310.11714C-100000@andante.jic.com>
Hi,
On Fri, 16 Oct 1998 22:34:25 -0400 (EDT), Eric Youngdale
<eric@andante.jic.com> said:
> This all sounds correct. The main problem is that Linux
> currently dosn't attempt to track the possibility that a second host is
> attached to the bus. If we did have such knowledge, then the next bit
> would be that we would need to account for this in some way. Some of the
> things I can think of offhand:
> 1) The error handling code probably needs to be adjusted. Mainly
> we would probably want to avoid resets unless we are trying to take away a
> reservation for some reson.
Probably true. Leonard, I know that the bus logics do work in the
normal case with multiple hosts, but do you happen to know how the error
handling is affected if things go wrong?
> 2) In the multi-initiator case, we would probably want to reserve
> the devices.
We should have the option of reserving devices, yes. For one thing,
some systems rely on disk reservation to synchronise failover. However,
look at http://gfs.lcse.umn.edu/: the GFS filesystem supports
simultaneous access to the disk by multiple hosts (currently only tested
on fibre-channel, however).
> The first step I guess would be to try and detect the presence of
> a 2nd initiator on the bus. I have never tried it, but it is
> theoretically possible that during bus scan it will turn up in one
> form or another.
That won't help in the common case where you start up one host before
the other: with multiple hosts, you have to be able to deal with hosts
becoming active on the bus after you boot yourself (especially in
cluster configurations where recovery from host failure is the whole
point in having the shared scsi bus).
--Stephen
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.rutgers.edu
