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
next prev parent 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).