Thread (6 messages) flat view 6 messages, 4 authors, 2012-05-09

Re: Interesting feature request for linux raid, waking up drives

From: Larkin Lowrey <hidden>
Date: 2012-05-09 20:06:55

I second this suggestion but I don't think it's the job of the raid
layer to keep track of whether the member drives are spinning or not.

I have implemented a similar setup to this but am suffering from the
sequential spin-up problem you described. It would be nice to have a
solution.

A userspace daemon could probably do the job. I found that relying on
the drive's internal power management for spinning them down was
unreliable (especially for WDC "green" drives) so I implemented a script
that watches /sys/block/sdX/stat for activity and spins down the drive
directly (via hdparm) when no activity has been posted for a
configurable period of time. A daemon process that was responsible for
spinning down the constituent drives could also be responsible for
spinning them up by watching /sys/block/mdX/stat for pending transfers.
Perhaps you and I could work on such a project.

One thing mdadm could do which would help greatly is to enumerate the
member disk block devices (not just partitions or member raid devices)
for a given array. This information is known since concurrent sync
operations are serialized so no two sync operations occur at the same
time on the same physical devices.

--Larkin

On 5/9/2012 12:37 PM, Patrik Horník wrote:
Hello Neil,

I want to propose some functionality for linux raid subsystem that I
think will be very practical for many users, automatic waking of
drives. I am using my own user land script written years ago to do
that and I dont know if there is some standard solution now. If there
is some, please point me to it.

I am using couple of big RAID5 arrays in servers working like NASes in
small office and home, which are in use only small part of the day. I
am using low power server and aggressive power saving settings on HDDs
to make power consumption substantially lower, for example drives are
going to sleep after 15 min of inactivity. Normally problem with such
settings is extremely long waking time when array is accessed.
Software accessing data often first requests only chunk of data on
first drive in array and waiting cca 20-30 sec for them, after
processing them accessing data on another drive and waiting another
20-30 sec and so on.

I solved it with my own script in PHP, which monitors drives' status
periodically. When it detects that drive from RAID array woke up, it
immediately wakes other drives. So total waking time is equal to
waking of one drive plus couple of seconds. It works perfectly and
smoothly for years for me.

I attached the script from one of my servers, it is little cruel and
using hwparm and smartctl to monitor and manipulating drives. It is
little customized and specific for its server, for example one drive
detected by model is not used to wake up other drives and two drives
are also putting one another into sleep, because I found out the
standby timeout setting was not working reliable on one drive. But you
will get the idea.

I think it could be useful for some users if there is possibility to
use such feature. Do you think it would be useful? Do you think there
is some place in linux raid infrastructure where it can be somehow
implemented? (Possibly as some user land tool using some kernel APIs,
I dont know.)

Best regards,

Patrik Horník
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help