From: "Marc Marais" <marcm@liquid-nexus.net>
To: Neil Brown <neilb@suse.de>
Cc: linux-raid@vger.kernel.org
Subject: Re: mdadm --grow failed
Date: Sun, 18 Feb 2007 17:20:47 +0800 [thread overview]
Message-ID: <20070218091504.M97223@liquid-nexus.net> (raw)
In-Reply-To: <17878.49009.771973.884472@notabene.brown>
Ok, I understand the risks which is why I did a full backup before doing
this. I have subsequently recreated the array and restored my data from
backup.
Just for information, the e2fsck -n on the drive hung (unresponsive with no
I/O) so I assume the filesystem was hosed. I suspect resyncing the array
after the grow failed was a bad idea.
I'm not sure how the grow operation is performed but to me it seems that
their is no fault tolerance during the operation so any failure will cause a
corrupt array. My 2c would be that if any drive fails during a grow
operation that the operation is aborted in such a way as to allow a restart
later (if possible) - as in my case a retry would've probably worked.
Anyway, if you need more info to help improve growing arrays let me know.
As a side note, either my hardware (Promise TX4000) card is acting up or
there are still some unresolved issues with libata in general and/or
sata_promise itself.
Regards,
Marc
On Sat, 17 Feb 2007 19:40:17 +1100, Neil Brown wrote
> On Saturday February 17, marcm@liquid-nexus.net wrote:
> >
> > Is my array destroyed? Seeing as the sda disk wasn't completely synced
I'm
> > wonder how it was using to resync the array when sdc went offline. I've
got
> > a bad feeling about this :|
>
> I can understand your bad feeling...
> What happened there shouldn't happen, but obviously it did. There is
> evidence that all is not lost but obviously I cannot be sure yet.
>
> Can you "fsck -n" the array? does the data still seem to be intact?
>
> Can you report exactly what version of Linux kernel, and of mdadm you
> are using, and give the output of "mdadm -E" on each drive.
>
> I'll try to work out what happened and how to go forward, but am
> unlikely to get back to you for 24-48 hours (I have a busy weekend:-).
>
> NeilBrown
--
next prev parent reply other threads:[~2007-02-18 9:20 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-02-17 3:22 mdadm --grow failed Marc Marais
2007-02-17 8:40 ` Neil Brown
2007-02-18 9:20 ` Marc Marais [this message]
[not found] ` <17880.7869.963793.706096@notabene.brown>
[not found] ` <20070218105242.M29958@liquid-nexus.net>
2007-02-18 11:57 ` Fw: " Marc Marais
2007-02-18 12:13 ` Justin Piszcz
2007-02-18 12:32 ` Marc Marais
2007-02-19 4:43 ` sata_promise: random/intermittent errors Marc Marais
2007-02-19 5:41 ` mdadm --grow failed Marc Marais
2007-02-19 13:25 ` Justin Piszcz
2007-02-19 0:50 ` Neil Brown
2007-02-17 18:27 ` Bill Davidsen
2007-02-17 19:16 ` Justin Piszcz
2007-02-17 21:08 ` Neil Brown
2007-02-17 21:30 ` Justin Piszcz
2007-02-18 11:51 ` David Greaves
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=20070218091504.M97223@liquid-nexus.net \
--to=marcm@liquid-nexus.net \
--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.