From: Elias Oltmanns <eo@nebensachen.de>
To: Tejun Heo <htejun@gmail.com>
Cc: Valdis.Kletnieks@vt.edu, Alan Cox <alan@lxorguk.ukuu.org.uk>,
Andrew Morton <akpm@linux-foundation.org>,
Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>,
Jeff Garzik <jeff@garzik.org>,
Randy Dunlap <randy.dunlap@oracle.com>,
linux-ide@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/4] libata: Implement disk shock protection support
Date: Fri, 12 Sep 2008 12:15:22 +0200 [thread overview]
Message-ID: <87prn9y8jp.fsf@denkblock.local> (raw)
In-Reply-To: <48C9A8D3.60408@gmail.com> (Tejun Heo's message of "Fri, 12 Sep 2008 01:25:07 +0200")
Tejun Heo <htejun@gmail.com> wrote:
> Valdis.Kletnieks@vt.edu wrote:
>> On Thu, 11 Sep 2008 15:01:00 +0200, Tejun Heo said:
>
>>> Ah.. just one more thing.
>>>
>>> I think it would be easier on the application if the written timeout
>>> value is cropped if it's over the maximum instead of failing the
>>> write.
>>
>> Which is better, failing the write so the application *knows* there is a
>> problem, or letting the application proceed with a totally incorrect idea of
>> what the value is set to?
>
> It depends. As -EINVAL either results in program failure or no
> protection for the event.
>
>> For instance, what happens if the program tries to set 100, it's silently
>> clamped to 10, and it then tries to set a timer for itself to '90% of the
>> value'? It might be in for an unpleasant surprise when it finds out that
>> it's overshot by 81....
>
> Hitting the limit would be a pretty rare occasion and which way we go
> it's not gonna be too pretty. e.g. Let's say a program calculates
> timeout according to some algorithm which 99.9% of the time stays in
> the limit but once in the blue moon hits the ceiling. Given the
> characteristics of the problem and very high limit value, I think it's
> better to have cropped value.
>
> How about returning -OVERFLOW while still setting the timeout to the
> maximum?
Yes, that makes sense. I'll take care to document it that way:
-EINVAL for values < -2, -EOVERFLOW for values > 30000.
Once we have smoothed things out wrt the ide patch, I'll repost the
whole series against a recent linux-next tree, so it can be queued up
for 2.6.28. By the way, the ide patch I've just posted does pretty much
what libata should be aiming for in the long run. Hopefully, it'll work
out as expected. Anyway, I'm really grateful to Bart and you for holding
my hand so patiently with all this.
Also, I'll backport the patches to 2.6.27 and make appropriate changes
to hdapsd, so we can get feedback from a wider range of testers. Since
there has been no comment from Jeff as yet, I'll wait with that until
the patches have been merged though.
Regards,
Elias
next prev parent reply other threads:[~2008-09-12 10:17 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-08-29 21:11 [RFC] Disk shock protection in GNU/Linux (take 2) Elias Oltmanns
2008-08-29 21:16 ` [PATCH 1/4] Introduce ata_id_has_unload() Elias Oltmanns
2008-08-30 11:56 ` Sergei Shtylyov
2008-08-30 17:29 ` Elias Oltmanns
2008-08-30 18:01 ` Sergei Shtylyov
2008-08-29 21:20 ` [PATCH 2/4] libata: Implement disk shock protection support Elias Oltmanns
2008-08-30 9:33 ` Tejun Heo
2008-08-30 23:38 ` Elias Oltmanns
2008-08-31 9:25 ` Tejun Heo
2008-08-31 12:08 ` Elias Oltmanns
2008-08-31 13:03 ` Tejun Heo
2008-08-31 14:32 ` Bartlomiej Zolnierkiewicz
2008-08-31 17:07 ` Elias Oltmanns
2008-08-31 19:35 ` Bartlomiej Zolnierkiewicz
2008-09-01 15:41 ` Elias Oltmanns
2008-09-01 2:08 ` Henrique de Moraes Holschuh
2008-09-01 9:37 ` Matthew Garrett
2008-08-31 16:14 ` Elias Oltmanns
2008-09-01 8:33 ` Tejun Heo
2008-09-01 14:51 ` Elias Oltmanns
2008-09-01 16:43 ` Tejun Heo
2008-09-03 20:23 ` Elias Oltmanns
2008-09-04 9:06 ` Tejun Heo
2008-09-04 17:32 ` Elias Oltmanns
2008-09-05 8:51 ` Tejun Heo
2008-09-10 13:53 ` Elias Oltmanns
2008-09-10 14:40 ` Tejun Heo
2008-09-10 19:28 ` Elias Oltmanns
2008-09-10 20:23 ` Tejun Heo
2008-09-10 21:04 ` Elias Oltmanns
2008-09-10 22:56 ` Tejun Heo
2008-09-11 12:26 ` Elias Oltmanns
2008-09-11 12:51 ` Tejun Heo
2008-09-11 13:01 ` Tejun Heo
2008-09-11 18:28 ` Valdis.Kletnieks
2008-09-11 23:25 ` Tejun Heo
2008-09-12 10:15 ` Elias Oltmanns [this message]
2008-09-12 18:11 ` Valdis.Kletnieks
2008-09-17 15:26 ` Elias Oltmanns
2008-08-29 21:26 ` [PATCH 3/4] ide: " Elias Oltmanns
2008-09-01 19:29 ` Bartlomiej Zolnierkiewicz
2008-09-03 20:01 ` Elias Oltmanns
2008-09-03 21:33 ` Elias Oltmanns
2008-09-05 17:33 ` Bartlomiej Zolnierkiewicz
2008-09-12 9:55 ` Elias Oltmanns
2008-09-12 11:55 ` Elias Oltmanns
2008-09-15 19:15 ` Elias Oltmanns
2008-09-15 23:22 ` Bartlomiej Zolnierkiewicz
2008-09-17 15:28 ` Elias Oltmanns
2008-08-29 21:28 ` [PATCH 4/4] Add documentation for hard disk shock protection interface Elias Oltmanns
2008-09-08 22:04 ` Randy Dunlap
2008-09-16 16:53 ` Elias Oltmanns
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=87prn9y8jp.fsf@denkblock.local \
--to=eo@nebensachen.de \
--cc=Valdis.Kletnieks@vt.edu \
--cc=akpm@linux-foundation.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=bzolnier@gmail.com \
--cc=htejun@gmail.com \
--cc=jeff@garzik.org \
--cc=linux-ide@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=randy.dunlap@oracle.com \
/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).