From mboxrd@z Thu Jan 1 00:00:00 1970 From: Johannes Moos Subject: Re: Data recovery from linear array (Intel SS4000-E) Date: Sat, 15 Oct 2011 14:44:39 +0200 Message-ID: <4E998037.50204@gmx.de> References: <4E972C82.1020605@gmx.de> <4E97539D.8040007@turmel.org> <4E985902.1070606@gmx.de> <4E98ECC1.8080403@turmel.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <4E98ECC1.8080403@turmel.org> Sender: linux-raid-owner@vger.kernel.org To: Phil Turmel , linux-raid@vger.kernel.org List-Id: linux-raid.ids Hi Phil, here's my current status: root@ThinkPad /media/Backup/NAS # mdadm --zero-superblock /dev/loop{0,1,3} root@ThinkPad /media/Backup/NAS # mdadm --create --chunk=64 --metadata=0.90 --level=linear -n 4 /dev/md0 /dev/loop{0,1,2,3} mdadm: partition table exists on /dev/loop0 but will be lost or meaningless after creating array Continue creating array? n mdadm: create aborted. I answered 'no' and checked the loop devices with disktype: root@ThinkPad /media/Backup/NAS # disktype /dev/loop{0,1,2,3} --- /dev/loop0 Block device, size 297.7 GiB (319668830208 bytes) DOS/MBR partition map Partition 1: 7.844 MiB (8224768 bytes, 16064 sectors from 1) Type 0x77 (Unknown) Partition 2: 1.490 TiB (1638736625152 bytes, 3200657471 sectors from 16065) Type 0x88 (Unknown) --- /dev/loop1 Block device, size 297.7 GiB (319668830208 bytes) --- /dev/loop2 Block device, size 465.4 GiB (499703758848 bytes) Blank disk/medium --- /dev/loop3 Block device, size 465.4 GiB (499703758848 bytes) fdisk output: root@ThinkPad /usr/src/linux # fdisk -l /dev/loop0 Disk /dev/loop0: 319.7 GB, 319668830208 bytes 255 heads, 63 sectors/track, 38864 cylinders, total 624353184 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/loop0p1 1 16064 8032 77 Unknown /dev/loop0p2 16065 3200673535 1600328735+ 88 Linux plaintext After examining /dev/loop0 with hexdump I found LVM on there as well: hexdump -C /dev/loop0 | head -n 116 00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 000001c0 02 00 77 fe 3f 00 01 00 00 00 c0 3e 00 00 00 00 |..w.?......>....| 000001d0 01 01 88 fe ff ff c1 3e 00 00 3f 28 c6 be 00 00 |.......>..?(....| 000001e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000001f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa |..............U.| 00000200 3c 49 50 53 74 6f 72 50 61 72 74 69 74 69 6f 6e |..| 00000320 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00000400 3c 44 79 6e 61 6d 69 63 44 69 73 6b 53 65 67 6d |...............| 000008a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 007e0000 85 f0 10 60 4b ea f7 df 00 00 00 f8 00 00 00 01 |...`K...........| 007e0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 007e1000 5d 10 f0 85 00 00 00 00 00 00 20 00 e5 bb 68 48 |]......... ...hH| 007e1010 7f 2b 00 00 00 00 00 00 00 00 00 00 08 00 00 00 |.+..............| 007e1020 00 20 00 00 aa 58 27 50 01 00 00 00 00 00 00 00 |. ...X'P........| 007e1030 00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 |................| 007e1040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 007e1100 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................| * 007e1500 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00ae0000 58 46 53 42 00 00 10 00 00 00 00 00 00 04 00 00 |XFSB............| 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). But the guy in the forum had no problem assembling his array, so I have to proceed with that first. Just wanted to make sure that it's OK to answer 'yes' and let mdadm do its job? Best regards, Johannes Moos