geom_fox? (multipathing)

Pawel Jakub Dawidek nick at garage.freebsd.pl
Thu Jan 29 13:35:52 PST 2004


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 quarantine] 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 quarantine] 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 quarantine] 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.

-- 
Pawel Jakub Dawidek                       pawel at dawidek.net
UNIX Systems Programmer/Administrator     http://garage.freebsd.pl
Am I Evil? Yes, I Am!                     http://cerber.sourceforge.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 305 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-geom/attachments/20040129/89018661/attachment.bin


More information about the freebsd-geom mailing list