Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933639AbbFJPCE (ORCPT ); Wed, 10 Jun 2015 11:02:04 -0400 Received: from mx1.redhat.com ([209.132.183.28]:42870 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S964839AbbFJPBx (ORCPT ); Wed, 10 Jun 2015 11:01:53 -0400 Date: Wed, 10 Jun 2015 10:01:51 -0500 From: David Teigland To: Goldwyn Rodrigues Cc: linux-kernel@vger.kernel.org, NeilBrown Subject: Re: clustered MD Message-ID: <20150610150151.GA333@redhat.com> References: <20150609182102.GA4305@redhat.com> <55773DE1.7080107@suse.com> <20150609194505.GA17536@redhat.com> <557747AB.7080706@suse.com> <20150609203056.GB17536@redhat.com> <5577AFF4.6020505@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5577AFF4.6020505@suse.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2188 Lines: 47 On Tue, Jun 09, 2015 at 10:33:08PM -0500, Goldwyn Rodrigues wrote: > >>>some real world utility to warrant the potential maintenance effort. > >> > >>We do have a valid real world utility. It is to provide > >>high-availability of RAID1 storage over the cluster. The > >>distributed locking is required only during cases of error and > >>superblock updates and is not required during normal operations, > >>which makes it fast enough for usual case scenarios. > > > >That's the theory, how much evidence do you have of that in practice? > > We wanted to develop a solution which is lock free (or atleast > minimum) for the most common/frequent usage scenario. Also, we > compared it with iozone on top of ocfs2 to find that it is very > close to local device performance numbers. we compared it with cLVM > mirroring to find it better as well. However, in the future we would > want to use it with with other RAID (10?) scenarios which is missing > now. OK, but that's the second time you've missed the question I asked about examples of real world usage. Given the early stage of development, I'm supposing there is none, which also implies it's too early for merging. > >>What are the doubts you have about it? > > > >Before I begin reviewing the implementation, I'd like to better understand > >what it is about the existing raid1 that doesn't work correctly for what > >you'd like to do with it, i.e. I don't know what the problem is. > > David Lang has already responded: The idea is to use a RAID device > (currently only level 1 mirroring is supported) with multiple nodes > of the cluster. That doesn't come close to answering the question: exactly how do you want to use raid1 (I have no idea from the statements you've made), and exactly what breaks when you use raid1 in that way? Once we've established the technical problem, then I can fairly evaluate your solution for it. Isn't this process what staging is for? Dave -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/