From: "Marc L. de Bruin" <marc@debruin.org>
To: "Marc L. de Bruin" <marc@debruin.org>
Cc: linux-raid@vger.kernel.org
Subject: Re: Can't get drives containing spare devices to spindown
Date: Thu, 22 Jun 2006 06:49:22 +0200 [thread overview]
Message-ID: <449A2152.2040906@debruin.org> (raw)
In-Reply-To: <446395C0.5060502@debruin.org>
Marc L. de Bruin wrote:
> Situation: /dev/md0, type raid1, containing 2 active devices
> (/dev/hda1 and /dev/hdc1) and 2 spare devices (/dev/hde1 and /dev/hdg1).
>
> Those two spare 'partitions' are the only partitions on those disks
> and therefore I'd like to spin down those disks using hdparm for
> obvious reasons (noise, heat). Specifically, 'hdparm -S <value>
> <device>' sets the standby (spindown) timeout for a drive; the value
> is used by the drive to determine how long to wait (with no disk
> activity) before turning off the spindle motor to save power.
>
> However, it turns out that md actually sort-of prevents those spare
> disks to spindown. I can get them off for about 3 to 4 seconds, after
> which they immediately spin up again. Removing the spare devices from
> /dev/md0 (mdadm /dev/md0 --remove /dev/hd[eg]1) actually solves this,
> but I have no intention actually removing those devices.
>
> How can I make sure that I'm actually able to spin down those two
> spare drives?
I'm replying to myself here which seems pointless, but AFAIK I got no
reply and I still believe this is an interesting issue. :-)
Also, I have some extra info. After doing some research, it seems that
the busy-ness of the filesystem matters too? For example, if I create a
/dev/md1 on /dev/hdb1 and /dev/hdd1 with two spares on /dev/hdf1 and
/dev/hdh1, put a filesystem on /dev/md1, mount it, put the spare drives
to sleep (hdparm -S 5 /dev/hd[fh1]), and leave that filesystem alone
completely, every few minutes for to me no obvious reason those spare
drives will spin-up. I can only think of one reason: the md subsystem
has to put some meta-info (hashes?) about /dev/md1 on the spare drives.
If I use the filesystem on /dev/md1 more intensively, those 'every few
minutes' seems to become 'every 15 or so seconds'.
I may be completely wrong here (I'm no md guru), but maybe someone can
confirm this behaviour? And if so, is there a way to control it? And if
not, what could happen here?
For the original problem I can think of a solution: removing the spare
drives from the array, get them to spin-down and use the mdadm monitor
feature to trigger a script on a 'Failed' event which adds a spare to
that array and remove any spin-down time from that spare. However,
although this sort-of fixes the problem, there is still an extra short
period of time where the raid1 array is not protected. If the scripts
fails for whatever reason, the raid1 array might not be protected for a
long time. Also, from an architectural point of view, this is really bad
and should not be needed.
Thanks again for your time,
Marc.
next prev parent reply other threads:[~2006-06-22 4:49 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-05-11 19:51 Can't get drives containing spare devices to spindown Marc L. de Bruin
2006-05-30 16:39 ` Bill Davidsen
2006-06-22 4:49 ` Marc L. de Bruin [this message]
2006-06-22 5:05 ` Neil Brown
2006-06-22 5:22 ` Marc L. de Bruin
2006-06-22 5:32 ` Neil Brown
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=449A2152.2040906@debruin.org \
--to=marc@debruin.org \
--cc=linux-raid@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).