From mboxrd@z Thu Jan 1 00:00:00 1970 From: Drew Reusser Subject: Re: Issue with Raid 10 super block failing Date: Mon, 19 Nov 2012 16:44:58 +0000 Message-ID: References: <50A82267.9030802@turmel.org> <50A8F247.8060002@turmel.org> <50A91487.70806@turmel.org> <50A92F53.5080100@turmel.org> <50AA36AD.4080100@turmel.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Return-path: In-Reply-To: <50AA36AD.4080100@turmel.org> Sender: linux-raid-owner@vger.kernel.org To: Phil Turmel Cc: linux-raid@vger.kernel.org List-Id: linux-raid.ids On Mon, Nov 19, 2012 at 1:39 PM, Phil Turmel 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