summaryrefslogtreecommitdiffstats
path: root/Assemble.c
diff options
context:
space:
mode:
authorDoug Ledford <dledford@redhat.com>2009-04-08 17:32:55 +1000
committerNeilBrown <neilb@suse.de>2009-04-08 17:32:55 +1000
commita9934ce44184660332549965c7d83a6a023ffd33 (patch)
treee9c5511bd267a0a204904a23c9f1e9895be994f8 /Assemble.c
parentc9b6907ba0de7812139cad2dac2c13545810713f (diff)
downloadmdadm-a9934ce44184660332549965c7d83a6a023ffd33.tar.gz
mdadm-a9934ce44184660332549965c7d83a6a023ffd33.tar.xz
mdadm-a9934ce44184660332549965c7d83a6a023ffd33.zip
mdadm udev rules change
I'm not attaching a patch for this because it's so simple. Long story short, watching both add and change events in udev rules is bad for md devices. Specifically, the kernel will generate a change event on things like array stop, and on things like fdisk close. In the case of array stop, it can result in the array being assembled again immediately. In the case of fdisk close, the situation is worse. Let's say you stop all the md devices on some block device in order to repartition. You run fdisk, change the partition table, then issue a write of the table. The write of the table triggers the change event *before* the kernel updates the partition table in memory for the block device, causing udev to rerun the incremental rules on the old partition table and restart all the arrays you just stopped with the old partition table layout, at which point the kernel is unable to reread the partition table. So, once you've enable incremental assembly, it becomes apparent that what we really want is to only start devices on add, not on add|change. -- Doug Ledford <dledford@redhat.com>
Diffstat (limited to 'Assemble.c')
0 files changed, 0 insertions, 0 deletions