From: Phil Turmel <philip@turmel.org>
To: Johannes Moos <jmoos@gmx.de>
Cc: linux-raid@vger.kernel.org
Subject: Re: Data recovery from linear array (Intel SS4000-E)
Date: Sun, 16 Oct 2011 14:46:46 -0400 [thread overview]
Message-ID: <4E9B2696.6030500@turmel.org> (raw)
In-Reply-To: <4E9AFD02.9070600@gmx.de>
On 10/16/2011 11:49 AM, Johannes Moos wrote:
> Hi Phil,
>
> I recreated the Array and it started.
>
>> As you can see, the partition table corresponds to the size of the combined devices. Metadata type 0.90 is at the end of each member, so the first sector of loop0 will become the first sector of md0.
>
> Right, /dev/md0 now looks exactly the same as /dev/loop0:
>
> root@ThinkPad /media/Backup/NAS # fdisk -l /dev/md0
> Disk /dev/md0: 1638.7 GB, 1638744850432 bytes
> 255 heads, 63 sectors/track, 199232 cylinders, total 3200673536 sectors
> Units = sectors of 1 * 512 = 512 bytes
> Sector size (logical/physical): 512 bytes / 512 bytes
> I/O size (minimum/optimal): 512 bytes / 512 bytes
> Disk identifier: 0x00000000
>
> Device Boot Start End Blocks Id System
> /dev/md0p1 1 16064 8032 77 Unknown
> /dev/md0p2 16065 3200673535 1600328735+ 88 Linux plaintext
>
>>> From what I read in a forum it's possible to mount the XFS partition with an offset, in my case that would be 00ae0000 (last line in hexdump).
>> Shouldn't be necessary. I expect your LV w/ XFS to show up properly.
>
> Nothing happened, so I tried as described in the forum post I mentioned (about a pretty much identical NAS and so LVM):
Hmmm. pvs should have shown it.
> root@ThinkPad /media/Backup/NAS # hexdump -C /dev/md0 | head -n 150 | grep XFSB
> 00ae0000 58 46 53 42 00 00 10 00 00 00 00 00 00 04 00 00 |XFSB............|
>
> Offset for XFS-Partition is 00ae0000, that's 11403264 in decimal, so I tried (read only):
>
> root@ThinkPad /media/Backup/NAS # losetup -r -o 11403264 /dev/loop4 /dev/md0
>
> and then I got:
>
> root@ThinkPad /media/Backup/NAS # disktype /dev/loop4
> --- /dev/loop4
> Block device, size 1.490 TiB (1638733447168 bytes)
> XFS file system, version 4
> Volume name ""
> UUID 705BF11E-8F69-1CDA-8727-00004868BBE3 (DCE, v1)
> Volume size 1 GiB (1073741824 bytes, 262144 blocks of 4 KiB)
>
> Small progress, but volume size only 1 GiB?
> I didn't ran xfs_check or xfs_repair so far because there's probably a better way to do it :)
I'm a bit weak on XFS. Anyone else care to comment?
Phil
prev parent reply other threads:[~2011-10-16 18:46 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-13 18:22 Data recovery from linear array (Intel SS4000-E) Johannes Moos
2011-10-13 21:09 ` Phil Turmel
2011-10-14 15:45 ` Johannes Moos
2011-10-15 2:15 ` Phil Turmel
2011-10-15 12:44 ` Johannes Moos
2011-10-15 16:34 ` Phil Turmel
2011-10-16 15:49 ` Johannes Moos
2011-10-16 18:46 ` Phil Turmel [this message]
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=4E9B2696.6030500@turmel.org \
--to=philip@turmel.org \
--cc=jmoos@gmx.de \
--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