freebsd-dev/lib/geom/multipath/Makefile

# $FreeBSD$

PACKAGE=geom
.PATH: ${.CURDIR:H:H}/misc

GEOM_CLASS=	multipath

CFLAGS+=  -I${SRCTOP}/sys

.include <bsd.lib.mk>
First cut at GEOM based multipath. This is an active/passive{/passive...} arrangement that has no intrinsic internal knowledge of whether devices it is given are truly multipath devices. As such, this is a simplistic approach, but still a useful one. The basic approach is to (at present- this will change soon) use camcontrol to find likely identical devices and and label the trailing sector of the first one. This label contains both a full UUID and a name. The name is what is presented in /dev/multipath, but the UUID is used as a true distinguishor at g_taste time, thus making sure we don't have chaos on a shared SAN where everyone names their data multipath as "Fred". The first of N identical devices (and N may be 1!) becomes the active path until a BIO request is failed with EIO or ENXIO. When this occurs, the active disk is ripped away and the next in a list is picked to (retry and) continue with. During g_taste events new disks that meet the match criteria for existing multipath geoms get added to the tail end of the list. Thus, this active/passive setup actually does work for devices which go away and come back, as do (now) mpt(4) and isp(4) SAN based disks. There is still a lot to do to improve this- like about 5 of the 12 recommendations I've received about it, but it's been functional enough for a while that it deserves a broader test base. Reviewed by: pjd Sponsored by: IronPort Systems MFC: 2 months 2007-02-27 04:01:58 +00:00			`# $FreeBSD$`

pkgbase: Put geom utilities in their own package For most users it's not needed to boot and they are also available in the FreeBSD-rescue package in case an update break and FreeBSD-geom package isn't updated correctly. Differential Revision: https://reviews.freebsd.org/D36224 2022-07-22 08:19:07 +00:00			`PACKAGE=geom`
sbin: normalize paths using SRCTOP-relative paths or :H when possible This simplifies make logic/output MFC after: 1 month Sponsored by: Dell EMC Isilon 2017-03-04 11:33:01 +00:00			`.PATH: ${.CURDIR:H:H}/misc`
First cut at GEOM based multipath. This is an active/passive{/passive...} arrangement that has no intrinsic internal knowledge of whether devices it is given are truly multipath devices. As such, this is a simplistic approach, but still a useful one. The basic approach is to (at present- this will change soon) use camcontrol to find likely identical devices and and label the trailing sector of the first one. This label contains both a full UUID and a name. The name is what is presented in /dev/multipath, but the UUID is used as a true distinguishor at g_taste time, thus making sure we don't have chaos on a shared SAN where everyone names their data multipath as "Fred". The first of N identical devices (and N may be 1!) becomes the active path until a BIO request is failed with EIO or ENXIO. When this occurs, the active disk is ripped away and the next in a list is picked to (retry and) continue with. During g_taste events new disks that meet the match criteria for existing multipath geoms get added to the tail end of the list. Thus, this active/passive setup actually does work for devices which go away and come back, as do (now) mpt(4) and isp(4) SAN based disks. There is still a lot to do to improve this- like about 5 of the 12 recommendations I've received about it, but it's been functional enough for a while that it deserves a broader test base. Reviewed by: pjd Sponsored by: IronPort Systems MFC: 2 months 2007-02-27 04:01:58 +00:00
Rename the generic "CLASS" to the more specific "GEOM_CLASS". While I'm here remove redundancy and inconsistencies. Obtained from: Juniper Networks 2010-12-15 23:24:34 +00:00			`GEOM_CLASS= multipath`
First cut at GEOM based multipath. This is an active/passive{/passive...} arrangement that has no intrinsic internal knowledge of whether devices it is given are truly multipath devices. As such, this is a simplistic approach, but still a useful one. The basic approach is to (at present- this will change soon) use camcontrol to find likely identical devices and and label the trailing sector of the first one. This label contains both a full UUID and a name. The name is what is presented in /dev/multipath, but the UUID is used as a true distinguishor at g_taste time, thus making sure we don't have chaos on a shared SAN where everyone names their data multipath as "Fred". The first of N identical devices (and N may be 1!) becomes the active path until a BIO request is failed with EIO or ENXIO. When this occurs, the active disk is ripped away and the next in a list is picked to (retry and) continue with. During g_taste events new disks that meet the match criteria for existing multipath geoms get added to the tail end of the list. Thus, this active/passive setup actually does work for devices which go away and come back, as do (now) mpt(4) and isp(4) SAN based disks. There is still a lot to do to improve this- like about 5 of the 12 recommendations I've received about it, but it's been functional enough for a while that it deserves a broader test base. Reviewed by: pjd Sponsored by: IronPort Systems MFC: 2 months 2007-02-27 04:01:58 +00:00
sbin: normalize paths using SRCTOP-relative paths or :H when possible This simplifies make logic/output MFC after: 1 month Sponsored by: Dell EMC Isilon 2017-03-04 11:33:01 +00:00			`CFLAGS+= -I${SRCTOP}/sys`
Rename the generic "CLASS" to the more specific "GEOM_CLASS". While I'm here remove redundancy and inconsistencies. Obtained from: Juniper Networks 2010-12-15 23:24:34 +00:00
			`.include <bsd.lib.mk>`