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 ---
- Subject: Call for testers - f14 critpath update: mdadm
- From: Doug Ledford <dledford@xxxxxxxxxx>
- Date: Thu, 05 Aug 2010 15:44:47 -0400
- Delivered-to: devel@xxxxxxxxxxxxxxxxxxxxxxx
- Openpgp: id=CFBFF194
- Organization: Red Hat, Inc.
- Reply-to: Development discussions related to Fedora <devel@xxxxxxxxxxxxxxxxxxxxxxx>
- User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.10) Gecko/20100621 Fedora/3.0.5-1.fc13 Lightning/1.0b2pre Thunderbird/3.0.5
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 <dledford@xxxxxxxxxx> GPG KeyID: CFBFF194 http://people.redhat.com/dledford Infiniband specific RPMs available at http://people.redhat.com/dledford/InfinibandAttachment: signature.asc
Description: OpenPGP digital signature-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
--- End Message ---
-- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
