From owner-freebsd-current@FreeBSD.ORG Wed Sep 14 08:17:17 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F266D16A41F for ; Wed, 14 Sep 2005 08:17:16 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6919443D45 for ; Wed, 14 Sep 2005 08:17:13 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (junior.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.3/8.13.3) with ESMTP id j8E8H5P7034809; Wed, 14 Sep 2005 02:17:05 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <4327DC81.7040903@samsco.org> Date: Wed, 14 Sep 2005 02:17:05 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.8) Gecko/20050615 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Massimo References: <1126683752.4306.6.camel@massimo.datacode.it> In-Reply-To: <1126683752.4306.6.camel@massimo.datacode.it> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.8 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on pooker.samsco.org Cc: freebsd-current@freebsd.org Subject: Re: raid framework from OpenBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Sep 2005 08:17:17 -0000 Massimo wrote: > I would like to know what do you think about new OpenBSD raid framework > management. > http://marc.theaimsgroup.com/?l=openbsd-misc&m=112630095818062 > > Doesn't it seems good stuff which is good for consideration? > > Regards. Creating a unified management tool for multiple RAID architectures has been a Holy Grail for at least 10 years, if not longer. It's deceptively hard, though. While it sounds straight-forward and is relatively easy to do for 1 or 2 architectures, the vast differences in how different architectures work makes it quickly turn into a huge mess. This is especially true when it comes to topology discovery and management and asynchronous event notification. Often times the only course is to degrade to a very simple, lowest common denominator interface, which then starts to limit the usefulness of the tool. I've been involved in several professional projects in exactly this area, and it simply is very, very hard to do well. The OpenBSD work looks interesting, but unless they can demostrate useful operation on more than 1 or 2 architectures, it's not terribly impressive. That's not to say that it can't be done and be a success, but the amount of required effort should not be underestimated. It's relatively easy to come up with a framework and implement one architecture module in it, then tell everyone else to simply add more modules. Also, it's not clear from the email whether the tool has to be manually told to rescan and look for changes in the state of the array (not just SES/SAFTE changes of the component drives). Displaying status on demand is fine, but what admin sits in front of their terminal and refreshes their monitoring apps every 5 seconds? The key is to have a an event notification pipeline that can collect events in near real time, filter them in a configurable way, and send out email/pager alerts when appropriate. Also, what does this mean for a datacenter full of machines that need to be monitored? Does a remote terminal session need to be opened on each one in order for monitoring to work? But, even if this particular work degrades into only being a tool for AMI (I assume they mean MegaRAID) controllers, it's still useful and I give them credit for doing it. Scott