Bug#717190: Leaves RAID sync speed set to 0

[Michael Meskes]

I just uploaded 9.43-2 with the patch mentioned in this bug report. However,
I lack the hardware to test hdparm. So please test it before I file an
unblock request.

Thanks.

Michael
-- 
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org
Jabber: michael.meskes at gmail dot com
VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#717190: Leaves RAID sync speed set to 0

[Simon Elsbrock]

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.0 +
+++ hdparm-9.43/debian/hdparm.init  2014-11-16 14:07:21.0 +
@@ -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-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#717190: Leaves RAID sync speed set to 0

[Anthony DeRobertis]

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