Thank you Neil. I don't want to follow your suggestions, until I'm
sure that I've properly understood them.
See my responses and questions interleaved below.
On 31 May 2010 04:55, Neil Brown <neilb@xxxxxxx> wrote:
> Everything in -pre looks good to me. The big question is, of course, "Can you
> see you data?".
Not, not at present.
Did I mention in my original post that the data is organised in three
LVM2 logical volumes?
I can't currently mount any of the LVM volumes.
> sdj hasn't been a hot spare since October last year. It must has dropped out
> for some reason and you never noticed. For this reason it is good to put
> e.g. "spare=1" in mdadm.conf and have "mdadm --monitor" running to warn you
> about these things.
Sorry to be such a dummy, but could you give an example of where and
how to put these in mdadm.conf?
The current mdadm.conf file (minus comments):
DEVICE partitions
CREATE owner=root group=disk mode=0660 auto=yes
HOMEHOST <system>
MAILADDR root
ARRAY /dev/md1 level=raid10 num-devices=4
UUID=f4ddbd55:206c7f81:b855f41b:37d33d37
> Some odd has happened by "post-recovery-raid-diagnostics.txt". sdh4 and sdg4
> are no longer in sync. Did you have another crash on Sunday morning?
No. I don't think so.
> I suspect your first priority is to make sure these crashes stop happening.
There have been none since /dev/md1 failed to mount ... suggesting
that mdadm, the RAID array itself, or the LVM stuff on top of it
is/are the source of the crashes.
> Then try the "-Af" command again. That is (almost) never the wrong thing to
> do. It only put things together in a way that looks like it was right
> recently.
>
> So I suggest:
> 1/ make sure that whatever caused the machine to crash has stopped. Replace
> the machine if necessary.
> 2/ use "-Af" to force-assemble the array again.
> 3/ look in the array to see if your data is there.
> 4/ report the results.
Just tbe 100% sure. Should I include sdj4 in the assembly or merely
sd{f,g,h,i}4?
Dave
--
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
