linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Pim Zandbergen <P.Zandbergen@macroscoop.nl>
To: NeilBrown <neilb@suse.de>
Cc: Doug Ledford <dledford@redhat.com>, linux-raid@vger.kernel.org
Subject: Re: freshly grown array shrinks after first reboot - major data loss
Date: Thu, 08 Sep 2011 15:44:26 +0200	[thread overview]
Message-ID: <4E68C6BA.7020807@macroscoop.nl> (raw)
In-Reply-To: <20110908111049.08988921@notabene.brown>



On 8-9-2011 3:10, NeilBrown wrote:
> So your data*should*  have been back exactly as it was.  I am at a loss to
> explain why it is not.
The array contained an LVM VG that would not activate until grown back.
After growing back,
- one ext4 LV was perfectly intact
- one other could be fsck'd back to life without any damage
- a third one could be fsck'd back with leaving some stuff in lost+found
- three others were beyond repair.

The VG was as old as the array itself; the LV's were pretty fragmented.

It looked like the ext4 superblocks were shifted. I could see the superblock
with hexdump, but mount would not. fsck first had to repair the superblock
before anything else.

So my report that data was "wiped" by the sync process was incorrect.

> You ask for 'max' and it just says 'max' to the kernel.
> The kernel needs to do the testing - and currently it doesn't.
I hope/assume this is no problem for my newly created array.
>
> Thanks for your report, and my apologies for your loss.
No need to apologize ; the limitation was documented, and I could have
upgraded the metadata without data loss, had I waited longer for advice.
And I did have off-site backups for the important stuff.

I'm just reporting this so others may be spared this experience.

Thanks,
Pim


  reply	other threads:[~2011-09-08 13:44 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-01 15:28 freshly grown array shrinks after first reboot - major data loss Pim Zandbergen
2011-09-01 16:12 ` Pim Zandbergen
2011-09-01 16:16   ` Pim Zandbergen
2011-09-01 16:48     ` John Robinson
2011-09-01 17:21       ` Pim Zandbergen
2011-09-02  9:02         ` Pim Zandbergen
2011-09-02 10:33           ` Mikael Abrahamsson
2011-09-05 10:47             ` Pim Zandbergen
2011-09-01 16:31   ` Doug Ledford
2011-09-01 17:44     ` Pim Zandbergen
2011-09-01 18:17       ` Doug Ledford
2011-09-01 18:52         ` Pim Zandbergen
2011-09-01 19:41           ` Doug Ledford
2011-09-02  9:19             ` Pim Zandbergen
2011-09-02 11:06               ` John Robinson
2011-09-09 19:30                 ` Bill Davidsen
2011-09-08  1:10         ` NeilBrown
2011-09-08 13:44           ` Pim Zandbergen [this message]
2011-09-02  5:32       ` Simon Matthews
2011-09-02  8:53         ` Pim Zandbergen
2011-09-01 17:03   ` Robin Hill

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=4E68C6BA.7020807@macroscoop.nl \
    --to=p.zandbergen@macroscoop.nl \
    --cc=dledford@redhat.com \
    --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).