From owner-freebsd-geom@FreeBSD.ORG Tue Nov 1 22:24:14 2011 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 94AE7106566C for ; Tue, 1 Nov 2011 22:24:14 +0000 (UTC) (envelope-from gcubfg-freebsd-geom@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 248718FC13 for ; Tue, 1 Nov 2011 22:24:14 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1RLMke-0004rn-70 for freebsd-geom@freebsd.org; Tue, 01 Nov 2011 23:24:12 +0100 Received: from cpe-188-129-80-155.dynamic.amis.hr ([188.129.80.155]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 01 Nov 2011 23:24:12 +0100 Received: from ivoras by cpe-188-129-80-155.dynamic.amis.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 01 Nov 2011 23:24:12 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-geom@freebsd.org From: Ivan Voras Date: Tue, 01 Nov 2011 23:23:41 +0100 Lines: 51 Message-ID: References: <4EAF00A6.5060903@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: cpe-188-129-80-155.dynamic.amis.hr User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 In-Reply-To: <4EAF00A6.5060903@FreeBSD.org> Cc: freebsd-current@freebsd.org Subject: Re: RFC: GEOM MULTIPATH rewrite X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 22:24:14 -0000 On 31.10.2011. 21:10, Alexander Motin wrote: > Hi. > > Attempt to fix some GEOM MULTIPATH issues made me almost rewrite it. So > I would like to present my results and request for testing and feedback. Good ideas, gmultipath robustness is a very good thing. Active/active support is also useful if ordering issues can be solved. There's a Linux paper linked at http://en.wikipedia.org/wiki/Multipath_I/O ... but apparently it doesn't say much about this problem. Could a simple policy such as "block all IO iff an BIO_ORDERED request is being processed" work well enough? I'd only add that you should be careful to be compatible with old gmultipath metadata (see e.g. recent user reports with 9.0 auto-updating gmirror metadata). > The main changes: > - Improved locking and destruction process to fix crashes in many cases. > - Improved "automatic" configuration method to make it safe by reading > metadata back from all specified paths after writing to one. > - Added provider size check to reduce chance of conflict with other > GEOM classes. > - Added "manual" configuration method without using on-disk metadata. > - Added "add" and "remove" commands to manage paths manually. > - Failed paths 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 provider disconnection. IMHO it is > right to do if device was completely removed. > - Added optional Active/Active mode support. Unlike Active/Passive > mode, load evenly distributed between all working paths. If supported by > 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. > > Latest patch can be found here: > http://people.freebsd.org/~mav/gmultipath4.patch > > Feedbacks are welcome! > > Sponsored by: iXsystems, Inc. >