From: Neil Brown <neilb@suse.de>
To: hansbkk@gmail.com
Cc: "D.S. Ljungmark" <spider@skuggor.se>,
doug@easyco.com, linux-raid@vger.kernel.org
Subject: Re: md-raid and block sizes
Date: Tue, 28 Dec 2010 22:45:13 +1100 [thread overview]
Message-ID: <20101228224513.31e71638@notabene.brown> (raw)
In-Reply-To: <AANLkTin=-0CN-teD5p4H_nFbuZ944DVuDMku3FaD7uv7@mail.gmail.com>
On Tue, 28 Dec 2010 18:29:26 +0700 hansbkk@gmail.com wrote:
> This doesn't actually relate to the blocksize issue, but a caveat -
> I've heard that these "green" drives are not suitable for use in a
> RAID.
>
> The specific issue is apparently that these drives spin down very
> frequently, but most RAID implementations keep spinning them back up
> again just as frequently (perhaps unnecessarily?), thus causing undue
> wear and tear on the drives' mechanics and ultimately premature
> failure.
>
After a brief period of no writes, md will update the bitmap and/or the
superblock to record that the array is clean (it may update the bitmap at
other times too, but that is not relevant here).
If the auto-spindown time of the drive is less than the delay-before-marking
the-array-clean of md, then you could get extra spin-ups.
The delay for updating the superblock is in sysfs in the md/safe_mode_timeout
file which defaults to 0.2 seconds (200msec).
The delay for updating the bitmap is set by an mdadm option (--bitmap-delay
or something like that) when adding a bitmap to an array, and I think is
available in sysfs in md/bitmap/something in recent kernels.
The actual delay before a write is between 2 and 3 times this number.
I think it defaults to 5 seconds (hence 10 to 15 second delay).
So if the drive spins down sooner than 15 seconds after the last IO, there
could be a problem but tuning md can git rid of that problem.
If the drive spin-down time is longer than 15 seconds, they should be no
unnecessary spin-ups.
If anyone has any data on default spin-down times of these "green" drives I
would be keen to hear about it.
Thanks,
NeilBrown
next prev parent reply other threads:[~2010-12-28 11:45 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-27 12:00 md-raid and block sizes D.S. Ljungmark
2010-12-27 19:02 ` Doug Dumitru
2010-12-28 11:45 ` John Robinson
[not found] ` <AANLkTikWxCxVUO+O8MXRXRR7Y8R5xGC1Catv-EiNGcDj@mail.gmail.com>
2010-12-28 8:46 ` D.S. Ljungmark
2010-12-28 11:29 ` hansbkk
2010-12-28 11:45 ` Neil Brown [this message]
2010-12-28 11:50 ` Mikael Abrahamsson
2010-12-28 11:51 ` Roman Mamedov
2010-12-28 11:45 ` Roman Mamedov
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=20101228224513.31e71638@notabene.brown \
--to=neilb@suse.de \
--cc=doug@easyco.com \
--cc=hansbkk@gmail.com \
--cc=linux-raid@vger.kernel.org \
--cc=spider@skuggor.se \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.