On Mon, Oct 09 2017, Curt wrote: > On Mon, Oct 9, 2017 at 12:28 AM, NeilBrown <neilb@xxxxxxxx> wrote: >> On Sun, Oct 08 2017, Curt wrote: >> Theoretically that should work. Was it deliberate? (I cannot seem to >> find the start of the thread). > Yes and no, I ran the command, but it wasn't what I really wanted > and/or needed, so to speak. > > >> are all valid devices with the same event counts. They are the six that >> you need. >> To confirm that names haven't changed, you can: >> mdadm --examine /dev/sdg1 /dev/sdd1 /dev/sdc1 /dev/sda1 /dev/sde1 \ >> /dev/sdb | grep Events > > Yes, the numbers all match. >> >> and confirm all the numbers are the same. >> Then do the same and grep for "this" and confirm all the Raid Disk >> numbers are different. > confirmed >> >> Interesting that /dev/sdb is a whole device and the rest are partitions. >> I assume you know about that and why it is. > Just a mistake when I added it. >> >> What happens if you run the --assemble --update=revert-reshape command on >> these 6 devices (without --force)?? >> >> NeilBrown > I'll give it a try, but first a question and FYI. Earlier Phil had me > ddrescue sde1 because it had pending sectors I believe. Should I use > sde1 or sdz1(ddrescued version)? If sdz1 contains the same data as sde1, then use sdz1. > > Also when this whole thing started. md127_raid process was using 100% > cpu, but nothing seemed to be happening, No numbers changed, nothing > that I could tell anyway. Any suggestions on if the same thing > happens when I run the revert-reshape? Could one of my libraries be > behind a version somewhere? If md127_raid is using 100% then that is a kernel bug. If that happens, then find all processes that are spinning or are in 'D' state, and cat /proc/$PID/stack for each pid, and report all the output. NeilBrown
Attachment:
signature.asc
Description: PGP signature
