From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jon Nelson" Subject: Re: AWFUL reshape speed with raid5. Date: Fri, 1 Aug 2008 08:23:37 -0500 Message-ID: References: <48909578.9020307@tmr.com> <18578.27191.869553.910780@notabene.brown> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <18578.27191.869553.910780@notabene.brown> Content-Disposition: inline Sender: linux-raid-owner@vger.kernel.org To: Neil Brown Cc: Justin Piszcz , Bill Davidsen , LinuxRaid List-Id: linux-raid.ids On Thu, Jul 31, 2008 at 8:43 PM, Neil Brown wrote: > I note that while in the original mail in this thread you were talking > about growing an array by adding drives, you are now talking about > growing an array by using more space on each drive. This change threw > me at first... True. Mea Culpa. >> Remaining questions: >> >> 1. Why does the version of metadata matter so much in a --grow --size operation? > > I cannot measure any significant different. Could you give some > precise details of the tests you run and the results you get ? I'll try to throw some stuff together soon. >> 2. There appear to be bugs when a bitmap is used. Can somebody else confirm? > > Confirmed. If you --grow an array with a bitmap, you will hit > problems as there is no mechanism to grow the bitmap. > What you need to do is to remove the bitmap, do the 'grow', then > re-add the bitmap. > I thought I had arranged that a grow would fail if there was a bitmap > in place, but I guess not. > I'll have a look into this. A small suggestion: to avoid trepidation, perhaps a small note like "you may re-add the bitmap while the array is still rebuilding/growing/whatever" would help to avoid some worry. There are two other solutions: Have the underlying code grow the bitmap (probably hard), or have it automatically remove+re-add the bitmap. -- Jon