From: Jeff Garzik <jgarzik@pobox.com>
To: Jens Axboe <axboe@suse.de>
Cc: Bartlomiej Zolnierkiewicz <B.Zolnierkiewicz@elka.pw.edu.pl>,
"Prakash K. Cheemplavam" <prakashkc@gmx.de>,
marcush@onlinehome.de, linux-kernel@vger.kernel.org,
eric_mudama@Maxtor.com
Subject: Re: Silicon Image 3112A SATA trouble
Date: Sun, 30 Nov 2003 11:41:55 -0500 [thread overview]
Message-ID: <3FCA1DD3.70004@pobox.com> (raw)
In-Reply-To: <20031130162523.GV10679@suse.de>
Jens Axboe wrote:
> On Sun, Nov 30 2003, Bartlomiej Zolnierkiewicz wrote:
>>Hmm. actually I was under influence that we have generic ioctls in 2.6.x,
>>but I can find only BLKSECTGET, BLKSECTSET was somehow lost. Jens?
>
>
> Probably because it's very dangerous to expose, echo something too big
> and watch your data disappear.
IMO, agreed.
Max KB per request really should be set by the driver, as it's a
hardware-specific thing that (as we see :)) is often errata-dependent.
Tangent: My non-pessimistic fix will involve submitting a single sector
DMA r/w taskfile manually, then proceeding with the remaining sectors in
another r/w taskfile. This doubles the interrupts on the affected
chipset/drive combos, but still allows large requests. I'm not terribly
fond of partial completions, as I feel they add complexity, particularly
so in my case: I can simply use the same error paths for both the
single-sector taskfile and the "everything else" taskfile, regardless of
which taskfile throws the error.
(thinking out loud) Though best for simplicity, I am curious if a
succession of "tiny/huge" transaction pairs are efficient? I am hoping
that the drive's cache, coupled with the fact that each pair of
taskfiles is sequentially contiguous, will not hurt speed too much over
a non-errata configuration...
Jeff
next prev parent reply other threads:[~2003-11-30 16:42 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-11-25 13:59 Silicon Image 3112A SATA trouble Prakash K. Cheemplavam
2003-11-29 15:39 ` Prakash K. Cheemplavam
2003-11-29 16:38 ` Julien Oster
2003-11-29 16:54 ` Jeff Garzik
2003-11-29 17:07 ` Craig Bradney
2003-11-30 1:51 ` Prakash K. Cheemplavam
2003-11-29 16:56 ` Jeff Garzik
2003-11-29 17:41 ` Miquel van Smoorenburg
2003-11-29 18:39 ` Jeff Garzik
2003-11-29 20:24 ` Marcus Hartig
2003-11-30 2:00 ` Prakash K. Cheemplavam
2003-11-30 14:47 ` Bartlomiej Zolnierkiewicz
2003-11-30 15:52 ` Prakash K. Cheemplavam
2003-11-30 16:21 ` Bartlomiej Zolnierkiewicz
2003-11-30 16:25 ` Jens Axboe
2003-11-30 16:41 ` Jeff Garzik [this message]
2003-11-30 16:51 ` Jens Axboe
2003-11-30 16:58 ` Bartlomiej Zolnierkiewicz
2003-11-30 17:06 ` Jeff Garzik
2003-11-30 17:10 ` Jens Axboe
2003-11-30 17:22 ` Jeff Garzik
2003-11-30 17:31 ` Jens Axboe
2003-11-30 17:48 ` Jeff Garzik
2003-11-30 17:56 ` Vojtech Pavlik
2003-11-30 18:17 ` Jens Axboe
2003-11-30 18:19 ` Jeff Garzik
2003-11-30 18:22 ` Jens Axboe
2003-11-30 18:31 ` Jeff Garzik
2003-11-30 19:44 ` Vojtech Pavlik
2003-11-30 21:05 ` Yaroslav Klyukin
2003-11-30 17:08 ` Jens Axboe
2003-11-30 17:13 ` Bartlomiej Zolnierkiewicz
2003-11-30 17:13 ` Jens Axboe
2003-11-30 17:18 ` Jeff Garzik
2003-11-30 17:28 ` Jens Axboe
2003-11-30 17:41 ` Jeff Garzik
2003-11-30 17:45 ` Jens Axboe
2003-11-30 17:57 ` Jeff Garzik
2003-11-30 18:21 ` Jens Axboe
2003-11-30 19:04 ` Jeff Garzik
2003-11-30 19:39 ` Jens Axboe
2003-11-30 20:35 ` Jeff Garzik
2003-12-01 9:02 ` Jens Axboe
2003-11-30 17:19 ` Prakash K. Cheemplavam
2003-11-30 18:07 ` Bartlomiej Zolnierkiewicz
2003-11-30 21:34 ` Prakash K. Cheemplavam
2003-11-30 16:27 ` Jeff Garzik
2003-11-30 16:34 ` Bartlomiej Zolnierkiewicz
[not found] <Pine.LNX.4.44.0311291453550.838-100000@coffee.psychology.mcmaster.ca>
2003-11-30 16:45 ` Jeff Garzik
-- strict thread matches above, loose matches on Subject: below --
2003-11-30 17:52 Luis Miguel García
2003-11-30 17:13 ` Craig Bradney
2003-11-30 18:27 ` Jeff Garzik
2003-11-30 18:41 Luis Miguel García
2003-11-30 21:15 ` Craig Bradney
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=3FCA1DD3.70004@pobox.com \
--to=jgarzik@pobox.com \
--cc=B.Zolnierkiewicz@elka.pw.edu.pl \
--cc=axboe@suse.de \
--cc=eric_mudama@Maxtor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=marcush@onlinehome.de \
--cc=prakashkc@gmx.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 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.