Re: Issue with Raid 10 super block failing

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Nov 19, 2012 at 1:39 PM, Phil Turmel <philip@xxxxxxxxxx> wrote:
> Hi Drew,
>
> On 11/18/2012 02:10 PM, Drew Reusser wrote:
>
> [trim /]
>> Sorry - did not know the rules about top posting.  Is there something
>> specific in the dmesg you are looking for?  I tried to mount it again
>> and copied everything in the buffer.
>
> Here's what I wanted to see:
>
>> [270303.640240] EXT4-fs (md0): VFS: Can't find ext4 filesystem
>
> This suggests that the ext4 superblock isn't near the beginning like
> it's supposed to be.  One of the ways that happens with MD raid is if
> someone does "mdadm --create" and destroys their old raid superblocks.
>
> I went back and looked at:
>
>>   Creation Time : Thu Nov 15 16:08:02 2012
>
> and:
>
>>     Data Offset : 262144 sectors
>
> So you've re-created the MD array.  That's bad.  Chunk size and Data
> offset size and alignment defaults have changed in the past couple
> years, so re-creating an array with a different mdadm version can cause
> these problems.  You can also lose the original order of devices, with
> similar consequences.
>

Yes I did multiple creates to try to get the devices back together
after mdadm --Fail commands.  I did not know about the assemble
command yet and was following what "experts" were saying to try to
recover failed superblock errors after a reboot (which is what errors
I found).

> (Side note:  there's various pieces of advice floating around the
> internet on recovering a broken array that start with re-creating the
> array.  It's horribly wrong, and only a last resort, and only after
> recording all the details about the original array.)
>
> Unless you kept a copy of "mdadm --examine /dev/sd[abde]1" for the
> original array, this will be difficult to debug further.  Your best
> chance is to go back to the version of mdadm available when you first
> built the system and recreate with that, trying the various device order
> combinations.
>
> Don't attempt to mount to check for success.  First, use "fsck -n" to
> non-destructively check the FS.  If that gives few errors, then you can
> mount the FS.
>
> Phil

I don't have the original mdadm --examine as I never knew to keep a
copy of it.  I created this array when I installed Mint on this server
in August, so the the version I am running now is the same as the
version on the pen drive I am booting from.  I know the disks were all
the same.  I set them up intentionally so they would be identical.

here is the output of the fsck ..

mint mnt # fsck -n /dev/md0
fsck from util-linux 2.20.1
fsck: fsck.linux_raid_member: not found
fsck: error 2 while executing fsck.linux_raid_member for /dev/md0
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux RAID Wiki]     [ATA RAID]     [Linux SCSI Target Infrastructure]     [Linux Block]     [Linux IDE]     [Linux SCSI]     [Linux Hams]     [Device Mapper]     [Device Mapper Cryptographics]     [Kernel]     [Linux Admin]     [Linux Net]     [GFS]     [RPM]     [git]     [Yosemite Forum]


  Powered by Linux