All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.