From: Jeff Garzik <jgarzik@pobox.com>
To: Clem Taylor <clemtaylor@comcast.net>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Any news on a higher performance sata_sil SIL_QUIRK_MOD15WRITE workaround?
Date: Thu, 12 Aug 2004 02:43:23 -0400 [thread overview]
Message-ID: <411B118B.4040802@pobox.com> (raw)
In-Reply-To: <411AFD2C.5060701@comcast.net>
Clem Taylor wrote:
> I've been really disappointed by the performance of the Silicon Image
> 3114 on my new x86_box. I spent a bunch of time looking into the
> problem, thinking it was a software RAID5 or xfs issue causing 4K IOs.
> I don't know why I didn't notice the 'applying Seagate errata fix' in
> dmesg until after I did a bunch of performance testing and realized that
> it was a sata_sil issue.
>
> So, I was wondering what I can do about this problem? I am not currently
Get a different controller + disk combination.
> getting enough disk performance to justify the amount spent on the
> system or enough to satisfy the application I'm working on. Before I go
> out and purchase a 3ware controller and re-install the machine (ouch),
> is there any chance of a better work around in the near future? I'd be
> more than willing to test out a patch.
>
> Is the problem with really with nblocks % 15 == 1? Or is the problem
> with nblocks % 15 == 0? If it is the later and I'm using xfs with 4K
> blocks, couldn't I just turn off the workaround or will the RAID5 driver
> potentially break up larger requests?
The problem is that the Silicon Image controller sends unusual -- but
legal -- block sizes to the SATA device.
Older Seagates cannot cope with this unique, but spec-correct behavior.
This issue cannot even be worked around with "nblocks % 15 == 1", as was
previously thought. Using that formula just makes the problem harder to
reproduce.
Further, I don't have any plans to address the performance issue, since
the set of affected drives is finite.
> It would seem that the root of the problem is a Seagate issue. Does
> anyone know if Seagate fixed the problem with a firmware update?
You could find out for us, and let us know :)
Jeff
next prev parent reply other threads:[~2004-08-12 6:43 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-08-12 5:16 Any news on a higher performance sata_sil SIL_QUIRK_MOD15WRITE workaround? Clem Taylor
2004-08-12 6:43 ` Jeff Garzik [this message]
2004-08-12 12:00 ` Alan Cox
2004-08-12 15:16 ` Jeff Garzik
2004-08-12 19:59 ` Alan Cox
2004-08-12 21:03 ` Jeff Garzik
2004-08-12 20:37 ` Alan Cox
2004-08-13 4:18 ` Clem Taylor
2004-08-13 12:13 ` Alan Cox
2004-08-16 18:49 ` Eric Mudama
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=411B118B.4040802@pobox.com \
--to=jgarzik@pobox.com \
--cc=clemtaylor@comcast.net \
--cc=linux-kernel@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 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.