I noticed Doug didn't send this to test@ , so I'm forwarding it.
Unfortunately I don't have a RAID array to test with.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
--- Begin Message ---
I've submitted an updated f14 mdadm package (3.1.3-0.git20100804.2).
This update should fix a race condition in the handling of the mdadm
device map file. This file is responsible for mdadm knowing what
devices it has already seen during incremental assembly so that as new
devices show up, they can be added to the already created arrays. There
was a race condition in the locking around that file, which was fixed
with a patch I wrote. That patch didn't deal properly with dangling
lock files and so mdadm could hang if there was a stale lock file.
Upstream modified my patch to fix operation in the face of a stale lock
file (you can still generate a stale lock file, but now we deal with it
gracefully). I would very much like for this update to make it into f14
before we cut a release candidate, but since it's a critpath package,
that means it needs lots of positive karma and some QE love (I've
disabled karma automatism on the update, but I still need the karma to
push the update from testing to stable).
In particular, any testing that stresses simultaneous incremental
assembly is appreciated. For my own purposes, I created a series of
loopback devices, made a raid1 array on every pair of devices (I had 6
arrays total), then I would stop all arrays and run this command on the
command line:
for dev in loop{0..11}; do (mdadm -I /dev/$dev &); done
and check for proper assembly of all arrays. This could also be
beneficial with random killing of mdadm instances immediately after
putting them all in the background (at least some will be waiting on the
lock of the device map file, and they would be easy targets to kill I
would think...I'll leave that exercise up to the tester) followed by
rerunning the killed mdadm instances and making sure they recover from
the stale lock file and being killed mid operation OK.
In addition, it needs to be tested in a dracut environment just to make
sure that the initramfs generation hasn't been negatively impacted by
the update.
Obviously, the normal "it worked with my raid arrays" testing is also
much appreciated, but the above targeted testing is what's needed to
verify specifically the changes between the existing f14 build and the
current f14 build.
Any help getting this tested would be much appreciated.
The bodhi ticket:
https://admin.fedoraproject.org/updates/mdadm-3.1.3-0.git20100804.2.fc14
And if you feel like testing it on earlier releases, the other bodhi
tickets:
https://admin.fedoraproject.org/updates/mdadm-3.1.3-0.git20100804.2.fc13
https://admin.fedoraproject.org/updates/mdadm-3.1.3-0.git20100804.2.fc12
Since the package has yet to hit the updates-testing repo, the package
link in the bodhi ticket will allow you to directly download the packages.
--
Doug Ledford <dledf...@redhat.com>
GPG KeyID: CFBFF194
http://people.redhat.com/dledford
Infiniband specific RPMs available at
http://people.redhat.com/dledford/Infiniband
signature.asc
Description: OpenPGP digital signature
--
devel mailing list
de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
--- End Message ---
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test
