From: Shaya Potter <spotter@gmail.com>
To: linux-raid@vger.kernel.org
Subject: Issue with moving LSI/Dell Raid to MD
Date: Sat, 16 Mar 2024 20:26:15 +0200 [thread overview]
Message-ID: <CALHdMH30LuxR4tz9jP2ykDaDJtZ3P7L3LrZ+9e4Fq=Q6NwSM=Q@mail.gmail.com> (raw)
note: not subscribed, so please cc me on responses.
I recently had a Dell R710 die where I was using the Perc6 to provide
storage to the box. As the box wasn't usable, I decided to image the
individual disks to a newer machine with significantly more storage.
I sort of messed up the progress, but that might have discovered a bug in mdadm.
Background, the Dell R710 supported 6 drives, which I had as a 1TB
SATA SSD and 5x8TB SATA disks in a RAID5 array.
In the process of imaging it, I I was setting up devices on /dev/loop
to be prepared to assemble the raid, but I think I accidentally
assembled the raid while imaging the last disk (which in effect caused
the last disk to get out of sync with the other disks. This was
initially ok, until the VM I was doing it on, crashed with a KVM/QEMU
failure (unsure what occurred).
I was hoping, it was going to be easy to bring up the raid array
again, but now mdadm was segfault on a null pointer exception whenever
I tried to assemble the array (was just trying the RAID5 portion).
I was thinking perhaps my VM got corrupted, but I couldn't figure that
out, so I decided to try and reimage the disks (more carefully this
time), but yes, the 5th disk was marked as in quick init, while the
others were more consistent.
Howvever, same segfault was occuring, so I built mdadm from source
(with -g and no -O, as an aside, this would be a good Makefile target
to have, to make issues easier to debug)
After understanding the issue, the segfault seems to be due to
Assemble.c wanting to call update_super() with a ddf super. Except
super-ddf.c doesn't provide that.
i.e. in Assemble.c it was crashing at
if (st->ss->update_super(st, &devices[j].i, UOPT_SPEC_ASSEMBLE, NULL,
c->verbose, 0, NULL)) {...}
which now explained the seg fault on null pointer exception. I was
able to progress past the segfault (perhaps badly, but it "seems" to
work for me), by putting in a null check before the update_super()
call, i.e.
if (st->ss->update_super && st->ss->update_super(....)) { ... }
thoughts about my "fix" (perhaps super-ddf.c needs an empty
update_super function?) , if this is a bug? (perhaps its unexpected
for me to have gotten into this state in the first place?)
next reply other threads:[~2024-03-16 18:26 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-16 18:26 Shaya Potter [this message]
2024-03-18 11:18 ` Issue with moving LSI/Dell Raid to MD Mariusz Tkaczyk
2024-03-18 11:42 ` Shaya Potter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CALHdMH30LuxR4tz9jP2ykDaDJtZ3P7L3LrZ+9e4Fq=Q6NwSM=Q@mail.gmail.com' \
--to=spotter@gmail.com \
--cc=linux-raid@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).