Re: [gentoo-user] Failed raid
On Sunday 24 September 2006 03:56, Richard Fish wrote: > Take a look at one of the good superblocks with mdadm --examine. That > should give you an idea of what options to give to create. You'll > want to make sure you use the same layout, chunksize, etc... Luckely I wrote down the exact command I used to create the array so that part should be easy. > You should then be able to recreate the array with mdadm --create > --assume-clean, and get access to your filesystem and data. I didn't pay attention to that option before. But now I tried it. The data on that array is not that important, most have been backed up elsewhere. It seemed to work. After recreating the array I ran fsck. The filesystem is ext3. It recovered the journal and cleared 5 orphaned inode and the filesystem seemed fine. I could mount it and access the data. The array synchronized again. For safety though I might copy the data elsewhere and recreate the filesystem from scratch. -- Jesper 01:17:47 up 17:42, 18 users, load average: 0.14, 0.19, 0.25 -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Failed raid
On 9/23/06, Jesper Fruergaard Andersen <[EMAIL PROTECTED]> wrote: looked around but cannot find any information about if or how this can be fixed. Is it possible to fix the superblock or force it in some way. I guess maybe they may be out of sync so the filesystem could be invalid if forced to start anyway. I *think* this will work. Or it might permanently trash your data. Unfortunately I don't have access to any raid arrays to test with atm. :-( Take a look at one of the good superblocks with mdadm --examine. That should give you an idea of what options to give to create. You'll want to make sure you use the same layout, chunksize, etc... You should then be able to recreate the array with mdadm --create --assume-clean, and get access to your filesystem and data. Check "man mdadm" for more details... Good luck. :-( -Richard -- gentoo-user@gentoo.org mailing list
[gentoo-user] Failed raid
I have a home server using 2.6.15-vs2.1.0-gentoo-r1 kernel. It has several raid arrays. The other day it froze, but I am away, so I had someone else turn it off and on again. After that 2 of the arrays didn't come up. One of them complained about invalid superblock on one partition but I added that back and it synchronized and that work fine again. However another array, md6, had 2 partitions complaining about invalid superblock as shown below. It should use the partitions /dev/hda8,/dev/hdc6,/dev/hdg7,/dev/hdh6,/dev/hde2 Two missing is one too many for raid 5 to just synchronize again. I have looked around but cannot find any information about if or how this can be fixed. Is it possible to fix the superblock or force it in some way. I guess maybe they may be out of sync so the filesystem could be invalid if forced to start anyway. But maybe it would be possible to force it long enough to mount the filesystem readonly for a while to retrieve those things not backed up elsewhere and the recreate the array from scratch? md: Autodetecting RAID arrays. md: invalid raid superblock magic on hdg7 md: hdg7 has invalid sb, not importing! md: invalid raid superblock magic on hdh6 md: hdh6 has invalid sb, not importing! md: autorun ... md: considering hdh7 ... ... md: considering hde2 ... md: adding hde2 ... md: adding hdc6 ... md: hdc2 has different UUID to hde2 md: hdc1 has different UUID to hde2 md: adding hda8 ... md: hda2 has different UUID to hde2 md: hda1 has different UUID to hde2 md: created md6 md: bind md: bind md: bind md: running: md: md6: raid array is not clean -- starting background reconstruction md: personality 4 is not loaded! md: do_md_run() returned -22 md: md6 stopped. md: unbind md: export_rdev(hde2) md: unbind md: export_rdev(hdc6) md: unbind md: export_rdev(hda8) ... -- Jesper 17:09:48 up 2 days, 59 min, 25 users, load average: 0.38, 0.88, 0.93 -- gentoo-user@gentoo.org mailing list
