From: Tejun Heo <tj@kernel.org>
To: Bruce Allen <ballen@gravity.phys.uwm.edu>,
IDE/ATA development list <linux-ide@vger.kernel.org>
Cc: Robert Krawitz <rlk@alum.mit.edu>,
Carlos Bessa <carlos.bessa@gmail.com>,
aladin7501-01@yahoo.de, webmaster@dragontower.de,
"Ivan N. Zlatev" <contact@i-nz.net>,
aliencoder@gmail.com, pascal@asmodeus.be,
andrew.vaselaar@trinity.edu"Ivan N. Zlatev" <contact@i-nz.net>,
aklitzing@online.de, Christian Wolf <wolfchri@gmail.com>
Subject: better solution for frequent head unload problem
Date: Wed, 01 Oct 2008 02:58:45 +0900 [thread overview]
Message-ID: <48E268D5.2090709@kernel.org> (raw)
Hello, Bruce and cc'd reporters.
I'm having a second thought about storage-fixup as solution for frequent
head unload problem. Initially, I thought there would be only a handful
of affected machines but it doesn't look like that anymore and
storage-fixup is too inflexible.
IMHO, this can be best dealt with by smartd if it can do the followings.
* smartd knows about most drive families - their l/ul limits and which
value to use to disable APM.
* it monitors u/ul limits and if the load count increases fast enough
that the drive reaches the limit before 1.5 years of uptime (or some
other value), it warns and automatically disables APM.
By doing the above, we don't have to maintain list of combinations of
system and harddrives which can never be complete and later when the
disk workload becomes different due to FS or VM changes, the powersaving
feature can be left enabled.
Obstacles are...
* How to build rather complete SMART database? I think vendor
cooperation is necessary. If we can work out something, it will also
improve general usefulness of SMART.
* Making distros enable smartd by default. smartd might need a bit of
adjustment but I think this shouldn't be too difficult.
What do you think?
Till we can figure out something, I'll keep building storage-fixup.conf.
Thanks.
--
tejun
reply other threads:[~2008-09-30 18:00 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=48E268D5.2090709@kernel.org \
--to=tj@kernel.org \
--cc=aladin7501-01@yahoo.de \
--cc=aliencoder@gmail.com \
--cc=andrew.vaselaar@trinity.edu \
--cc=ballen@gravity.phys.uwm.edu \
--cc=carlos.bessa@gmail.com \
--cc=contact@i-nz.net \
--cc=linux-ide@vger.kernel.org \
--cc=pascal@asmodeus.be \
--cc=rlk@alum.mit.edu \
--cc=webmaster@dragontower.de \
/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).