Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 29 Jan 2004 22:36:42 +0100
From:      Pawel Jakub Dawidek <nick@garage.freebsd.pl>
To:        Andrew - Supernews <andrew@supernews.net>
Cc:        freebsd-geom@freebsd.org
Subject:   Re: geom_fox? (multipathing)
Message-ID:  <20040129213642.GD72053@garage.freebsd.pl>
In-Reply-To: <E1AmImJ-0001In-6t@trinity.supernews.net>
References:  <E1AmImJ-0001In-6t@trinity.supernews.net>

next in thread | previous in thread | raw e-mail | index | archive | help

--2qXFWqzzG3v1+95a
Content-Type: text/plain; charset=iso-8859-2
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, Jan 29, 2004 at 08:28:34PM +0000, Andrew - Supernews wrote:
+> So I'm doing a little experimenting with FreeBSD and multipathing
+> (using a SAN-attached storage array). Has anyone else looked into this
+> to any extent, or should I just roll my sleeves up and fix anything
+> that breaks?

Currently multipathing with ISP driver is not possible, because ISP
driver when path is disconnected doesn't cancels request and doesn't
returns an error to upper layers and there is no chance to detect
such situation.

+> (I currently have a test environment for this stuff - dual-port Qlogic
+> FC card talking to two separate SAN switches with a hefty disk array
+> attached on both, and the ability to break any of the above at will in
+> order to test failure conditions. I don't know how much time I have
+> before I need to use the array for something else.)

GEOM_FOX AFAIK is only a proof-of-conecpt.
I've full, finished multipathing implementation called GEOM_ROME.
It support 3 algorithms of path selection:
1. Simple failover - when error is returned from a path, it is marked
   on given time as suspected and request goes to another path.
   After few (configurable) times of being suspected it is removed.
2. Round-robin - simple round-robin with failover, it allows to split
   requests between paths to improve performance.
3. "Smart" - path is selected depending on number of pending requests.

There is also a experimental workaround for ISP issue: there is a thread
that monitors sent requests and if request doesn't come back in given
number of seconds is canceled, path is marked as suspected and request is
sent through another path. It works well, but if path will be restored
and there were pending requests in ISP driver they may finish and some newer
data may be overwritten.

Paths are added in two ways:
1. "Automatic" - depending on on-disk metadata, such path is automatically
   added when disk shows up in system.
2. "Manual" - there is no need for on-disk metadata - user configures which
   disks are paths.

There is a configuration utility which looks like this:

usage: romeconfig create [-v] [-b balance] [-s slice] [-S suspects] [-q qua=
rantine] name path1 [path2 [...]]
       romeconfig destroy [-fv] name
       romeconfig attach [-v] name path1 [path2 [...]]
       romeconfig remove [-v] name path1 [path2 [...]]
       romeconfig operate [-v] [-b balance] [-s slice] [-S suspects] [-q qu=
arantine] name
       romeconfig enable [-v] name path1 [path2 [...]]
       romeconfig suspect [-v] name path1 [path2 [...]]
       romeconfig disable [-v] name path1 [path2 [...]]
       romeconfig label [-v] [-b balance] [-s slice] [-S suspects] [-q quar=
antine] name device1 [device2 [...]]
       romeconfig list
       balance can be: none, round-robin (rr), smart

BUT...
It was created on an order and I can't sell before ISP issue will be fixed.=
..
I hope it will be fixed soon and I'll be able to commit it.

--=20
Pawel Jakub Dawidek                       pawel@dawidek.net
UNIX Systems Programmer/Administrator     http://garage.freebsd.pl
Am I Evil? Yes, I Am!                     http://cerber.sourceforge.net

--2qXFWqzzG3v1+95a
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (FreeBSD)

iQCVAwUBQBl86j/PhmMH/Mf1AQFGsAP5Abns2OrO25kPQEIx0lMCvYNi9+8tVBV6
9O9h9zD471AsKJsYuS7Nzgu9nWqNr8td0ekg6uaN+2eYUOgGfNHFE39BTZe2uAwM
2pB0sn7ufEuNuFGLATG5eZd3i/tjzPFuCm4/CEB2SdzvLdEc18TxSVk9EwN8mwdw
SYC3KPhXs5o=
=ZiNF
-----END PGP SIGNATURE-----

--2qXFWqzzG3v1+95a--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040129213642.GD72053>