Control: tags -1 +patch
Hi,
README.Debian mentions problems with RAID setups, but it is not
mentioned anywhere else (especially not in the comment block of
RAID_WORKAROUND in /etc/default/hdparm).
I am unsure how fast a rebuild limit of 0 will be applied to current
subsystem operations. If it proves to be inherently unsafe, running
hdparm in RAID setups should be forbidden.
On Wed, 17 Jul 2013 14:08:12 -0400 Anthony DeRobertis
<aderober...@metrics.net> wrote:
> 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.
Do you mean hdparm operations being executed although RAID rebuild
operations have not yet come to a stop (caused by setting the speed
limit to 0)? Or is it something else?
> The most obvious approach to fix this is locking.
Here's a patch that would lock save/restore of speed synchronization
limits if RAID_WORKAROUND=yes.
Regards,
Simon
diff -Nru hdparm-9.43/debian/hdparm.init hdparm-9.43/debian/hdparm.init
--- hdparm-9.43/debian/hdparm.init 2014-11-16 14:07:21.000000000 +0000
+++ hdparm-9.43/debian/hdparm.init 2014-11-16 14:07:21.000000000 +0000
@@ -94,6 +94,7 @@
if [ -f /proc/sys/dev/raid/speed_limit_max ] && [ "x$raid_speed_limit_max"
!= "x" ]; then
echo $raid_speed_limit_max >/proc/sys/dev/raid/speed_limit_max
fi
+ rm -f /var/lock/hdparm-resync.lock
}
isOnBattery() {
@@ -146,6 +147,9 @@
# Turn off RAID synchronisation if needed and asked for.
if [ "$raidstat" != 'OK' ] && [ "$RAID_WORKAROUND" = "yes" ]; then
+ exec 200>/var/lock/hdparm-resync.lock
+ # Block until lock can be acquired
+ flock 200
slow_down_raid_sync
fi
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
