linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Haakon Alstadheim <hakon.alstadheim@gmail.com>
To: NeilBrown <neilb@suse.de>
Cc: linux-raid@vger.kernel.org
Subject: Re: Interrupted reshape -- mangled backup ?
Date: Thu, 18 Oct 2012 16:08:10 +0200	[thread overview]
Message-ID: <50800D4A.8090704@gmail.com> (raw)

(I'm copying to the list as well)

On 18. okt. 2012 00:33, NeilBrown wrote:
> On Wed, 17 Oct 2012 23:34:26 +0200 Haakon Alstadheim
> <hakon.alstadheim@gmail.com>  wrote:
>
>> I have a Raid5 array with 4 devices that I wanted to see if I could get
>> a better performance out of, so i tried changing the chunk size from 64K
>> to something bigger. (famous last words) .  I got into some other
>> trouble and thought I needed a reboot. On reboot I several times managed
>> to mount and specify the device with my backup file during initramfs,
>> but the reshape stopped every time once the system was at initialized.
> So worst-case you can do that again, but insert a "sleep 365d" immediately
> after the "mdadm --assemble" is run, so the system never completely
> initialises.  Then just wait for the reshape to finish.
Yes, well I need to keep my mail-server running :-). Couple of hours 
down-time each night is acceptable though.

>
> When mdadm assembles and array that needs to keep growing it will for a
> background process to continue monitoring the reshape process.  Presumably
> that background process is getting killed.  I don't know why.
>
>> This is under debian sqeeze with a 3.2.0-0.bpo.3-686-pae kernel from
>> backports. I installed mdadm from backports to get the latest version of
>> that as well, and tried rebooting with --freeze-reshape. Suspect that I
>> mixed up my initrd.img-files and started without --freeze-reshape the
>> first time after installing the new mdadm. Now mdadm says it can not
>> find a backup in my backup file. Opening up the backup in emacs, it
>> seems to contain only NULs. Can't be right, can it? I have been mounting
>> the backup under a directory under /dev/, on the assumption that the
>> mount wold survive past the initramfs stage.
> The backup file could certainly contain lots of nuls, but it shouldn't be
> *all* nulls.
I checked again, isearch-forward-regexp for [^^@] in emacs gives no 
hits. ^@ is the emacs way of displaying ASCII-NUL
>    At least there should be a header at the start which describes
> which area of the device is contained in the backup.
>
> You can continue without a backup.  You still need to specify a backup file,
> but if you add "--invalid-backup", it will continue even if the backup file
> doesn't contain anything useful.
Thanks! device is now running again. These switches are hard to google 
after. Especially when you are a bit stressed :-)
> If the machine was shutdown by a crash during reshape you might suffer
> corruption.  If it was a clean shutdown you won't.

No corruption yet, (last reboot without fsck though).

>
> --freeze-reshape is intended to be the way to handle this, with
>     --grow --continue
> once you are fully up and running, but I don't think that works correctly for
> 'native' metadata yet - it was implemented with IMSM metadata in mind.
>
> NeilBrown
You are right, mdadm segfaults when I try to do mdadm --grow --continue 
--backup-file=/dev/bak/md1-backup /dev/md1.

We'll se tonight at 04:15 whether my custom initramfs script can make 
some progress on the reshape, and continue booting without messing up 
the backup-file.

In my initramfs script, should I do the following ? :
1. Start the array
2. Sleep a while
3. Stop the array
4. Start with --freeze-reshape
5. Continue boot

... or is it just as well to live with the timestamps getting out of 
sync when the reshape dies? I.e skip the stop&restart bit ?



             reply	other threads:[~2012-10-18 14:08 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-18 14:08 Haakon Alstadheim [this message]
  -- strict thread matches above, loose matches on Subject: below --
2012-10-17 21:34 Interrupted reshape -- mangled backup ? Haakon Alstadheim
2012-10-17 22:33 ` NeilBrown

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=50800D4A.8090704@gmail.com \
    --to=hakon.alstadheim@gmail.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).