#
260478 |
|
09-Jan-2014 |
mav |
MFC r258220, r258251: Implement automatic live resize support for GEOM MULTIPATH class.
In "manual" mode just automatically resize provider in any direction. In "automatic" mode allow growth (with new metadata write); in case of shrinking check if there is already valid metadata found at the new location. This should allow easy transparent recovery if first resize was done by mistake.
While there, unify metadata write code and fix minor memory leak.
|
#
227464 |
|
12-Nov-2011 |
mav |
Major GEOM MULTIPATH class rewrite: - Improved locking and destruction process to fix crashes. - Improved "automatic" configuration method to make it consistent and safe by reading metadata back from all specified paths after writing to one. - Added provider size check to reduce chance of ordering conflict with other GEOM classes. - Added "manual" configuration method without using on-disk metadata. - Added "add" and "remove" commands to allow manage paths manually. - Failed paths are no longer dropped from geom, but only marked as FAIL and excluded from I/O operations. - Automatically restore failed paths when all others paths are marked as failed, for example, because of device-caused (not transport) errors. - Added "fail" and "restore" commands to manually control FAIL flag. - geom is now destroyed on last path disconnection. - Added optional Active/Active mode support. Unlike Active/Passive mode, load evenly distributed between all working paths. If supported by the device, it allows to significantly improve performance, utilizing bandwidth of all paths. It is controlled by -A option during creation. Disabled by default now. - Improved `status` and `list` commands output.
Sponsored by: iXsystems, inc. MFC after: 1 month
|
#
167050 |
|
27-Feb-2007 |
mjacob |
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
|