From: Neil Brown <neilb@suse.de>
To: Mark F <gnomeza@gmail.com>
Cc: linux-raid@vger.kernel.org
Subject: Re: Manually specifying data_offset in component device superblock?
Date: Thu, 9 Jul 2009 11:34:10 +1000 [thread overview]
Message-ID: <19029.18706.672808.169640@notabene.brown> (raw)
In-Reply-To: message from Mark F on Tuesday July 7
On Tuesday July 7, gnomeza@gmail.com wrote:
> Hi
>
> __The Problem__
>
> I'm attempting to recover a RAID5 (6 disks) with zeroed superblocks.
>
> mdadm -C --assume-clean -f -e 1.2 -l 5 -p ls -c 128 -n6
>
> But I'm unable to get the data offsets of some of the disks in the
> array to match what I had before:
> Diff of mdadm --examine /dev/sdb3 (which became /dev/sde3 after reboot)
>
>
> - Avail Dev Size : 870353369 (415.02 GiB 445.62 GB)
> + Avail Dev Size : 870353233 (415.02 GiB 445.62 GB)
> Array Size : 4351765760 (2075.08 GiB 2228.10 GB)
> Used Dev Size : 870353152 (415.02 GiB 445.62 GB)
> - Data Offset : 136 sectors
> + Data Offset : 272 sectors
That is unfortunate, isn't it...
>
> Data offset for this disk was originally 136, but on recreation, mdadm
> chooses 272...
It must have been created with mdadm-2.5.6 or earlier
>
> The array started off as RAID5 (5 disks plus a hot spare).
> One disk (array slot 4) failed about a year ago and was replaced.
> The array was grown to RAID5 (6 disks) shortly after.
>
> __The Question__
>
> So, is there a way to force a particular data offset? (short of
> recompiling mdadm?)
No.
>
> __Some things I've tried__
>
> It seems to be feasible to *manually* tweak data_offset with a hexeditor.
> To test things I've created some sparse loopback devices of the
> correct size (dd seek) with just the first 1MB or so of data in each
> device.
> After updating data_offset and the checksum of the first disk I
> assembled the array and cryptsetup found its header. (Yay!)
You would need to update the data_offset on each device.
>
> But does anyone know if other parts of the superblock are dependent on
> the data_offset value?
> Am I going to bork things horribly by fiddling with the data_offset?
No, that should be safe (as long as you do it on every device).
>
> What data is present between the end of the superblock and the
> beginning of data?
That space is used for an internal bitmap. If you don't have a bitmap
configured, then that space is not used.
NeilBrown
next prev parent reply other threads:[~2009-07-09 1:34 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-07-07 10:54 Manually specifying data_offset in component device superblock? Mark F
2009-07-07 14:03 ` Mark F
2009-07-09 1:34 ` Neil Brown [this message]
2009-07-09 22:11 ` Mark F
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=19029.18706.672808.169640@notabene.brown \
--to=neilb@suse.de \
--cc=gnomeza@gmail.com \
--cc=linux-raid@vger.kernel.org \
/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