Package: hdparm Version: 9.39-1+b1 Severity: grave File: /lib/udev/rules.d/85-hdparm.rules X-Debbugs-CC: anth...@derobert.net
I enabled RAID_WORKAROUND, and it managed to leave sync_speed_min and sync_speed_max set to 0. That of course had a degraded RAID array sitting there, not rebuilding—a scenario that puts data at great risk. Looking at the scripts, I think what happens is that 85-hdparm.rules calls the init script, which does: 1. save current value of sync speeds to variables 2. change both to 0. 3. call hdparm 4. restore from variables. but udev works in parallel, so multiple "hotplugs" can happen at once. Leading to a race: a1. save (200k) a2. change (from 200k to 0) b1. save (this will save 0!) a3. hdparm b2. change (from 0 to 0) b3. hdparm a4. restore (back to 200k) b4. restore (back to 0) (!) Of course, that race can go other ways, such as calling hdparm with the rebuild in progress (which supposedly corrupts data). Or both could happen. The most obvious approach to fix this is locking. There are related bugs, such as each RAID array actually can use a non-default set of sync speed parameters, set in /sys. But I think that can be documented and left to the user to solve. -- System Information: Debian Release: 7.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages hdparm depends on: ii libc6 2.13-38 ii lsb-base 4.1+Debian8+deb7u1 Versions of packages hdparm recommends: ii powermgmt-base 1.31 Versions of packages hdparm suggests: pn apmd <none> -- Configuration Files: /etc/default/hdparm changed: harddisks=/dev/sd[a-f] hdparm_opts="-B 255" RAID_WORKAROUND=yes -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
