linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Michael Tokarev <mjt@tls.msk.ru>
To: Neil Brown <neilb@suse.de>
Cc: Janek Kozicki <janek_listy@wp.pl>, linux-raid@vger.kernel.org
Subject: Re: very degraded RAID5, or increasing capacity by adding discs
Date: Tue, 09 Oct 2007 13:48:50 +0400	[thread overview]
Message-ID: <470B4E82.6010102@msgid.tls.msk.ru> (raw)
In-Reply-To: <18186.62585.7261.178442@notabene.brown>

Neil Brown wrote:
> On Tuesday October 9, mjt@tls.msk.ru wrote:
[]
>> o During this reshape time, errors may be fatal to the whole array -
>>   while mdadm do have a sense of "critical section", but the
>>   whole procedure isn't as much tested as the rest of raid code,
>>   I for one will not rely on it, at least for now.  For example,
>>   a power failure at an "unexpected" moment, or some plain-stupid
>>   error in reshape code so that the whole array goes "boom" etc...
> 
> While it is true that the resize code is less tested than other code,
> it is designed to handle a single failure at any time (so a power
> failure is OK as long as the array is not running degraded), and I
> have said that if anyone does suffer problems while performing a
> reshape, I will do my absolute best to get the array functioning and
> the data safe again.

Well... Neil, it's your code, so you trust it - that's ok, I also
(tries to) trust my code until someone finds a bug in it.. ;)
And I'm a sysadmin (among other things), who's professional
property must be a bit of paranoia..  You got the idea ;)

>> o A filesystem on the array has to be resized separately after
>>   re{siz,shap}ing the array.  And filesystems are different at
>>   this point, too - there are various limitations.  For example,
>>   it's problematic to grow ext[23]fs by large amounts, because
>>   when it gets initially created, mke2fs calculates sizes of
>>   certain internal data structures based on the device size,
>>   and those structures can't be grown significantly, only
>>   recreating the filesystem will do the trick.
> 
> This isn't entirely true.
> For online resizing (while the filesystem is mounted) there are some
> limitations as you suggest.  For offline resizing (while filesystem is
> not mounted) there are no such limitations.

There still is - at least for ext[23].  Even offline resizers
can't do resizes from any to any size, extfs developers recommend
to recreate filesystem anyway if size changes significantly.
I'm too lazy to find a reference now, it has been mentioned here
on linux-raid at least this year.  It's sorta like fat (yea, that
ms-dog filesystem) - when you resize it from, say, 501Mb to 999Mb,
everything is ok, but if you want to go from 501Mb to 1Gb+1, you
have to recreate almost all data structures because sizes of
all internal fields changes - and here it's much safer to just
re-create it from scratch than trying to modify it in place.
Sure it's much better for extfs, but the point is still the same.

/mjt

  reply	other threads:[~2007-10-09  9:48 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-08 19:13 very degraded RAID5, or increasing capacity by adding discs Janek Kozicki
2007-10-08 19:17 ` Justin Piszcz
2007-10-08 19:26 ` Richard Scobie
2007-10-08 20:08   ` Guy Watkins
2007-10-08 22:25   ` Janek Kozicki
2007-10-08 22:46     ` Janek Kozicki
2007-10-09  1:53       ` Guy Watkins
2007-10-09  3:32       ` Neil Brown
2007-10-09 14:44         ` Janek Kozicki
2007-10-09 14:56         ` Mr. James W. Laferriere
2007-10-09 21:52           ` Neil Brown
2007-10-08 22:52 ` Michael Tokarev
2007-10-09  3:24   ` Neil Brown
2007-10-09  9:48     ` Michael Tokarev [this message]
2007-10-22  9:03       ` Louis-David Mitterrand
2007-10-23 22:41         ` Bill Davidsen
2007-10-09 14:42   ` Janek Kozicki

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=470B4E82.6010102@msgid.tls.msk.ru \
    --to=mjt@tls.msk.ru \
    --cc=janek_listy@wp.pl \
    --cc=linux-raid@vger.kernel.org \
    --cc=neilb@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).