Any news on a higher performance sata_sil SIL_QUIRK_MOD15WRITE workaround?

Any news on a higher performance sata_sil SIL_QUIRK_MOD15WRITE workaround?

[Clem Taylor]

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 
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?

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? 
Updating the firmware on Seagate fibre channel drives was pretty 
painless, I'd assume that a method exists for SATA drives as well, or is 
that asking too much?

                 Thanks,
                 Clem

Re: Any news on a higher performance sata_sil SIL_QUIRK_MOD15WRITE workaround?

[Jeff Garzik]

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

Re: Any news on a higher performance sata_sil SIL_QUIRK_MOD15WRITE workaround?

[Alan Cox]

On Iau, 2004-08-12 at 07:43, Jeff Garzik wrote:
> 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.

It fixes it completely on the drivers/ide driver.

Re: Any news on a higher performance sata_sil SIL_QUIRK_MOD15WRITE workaround?

[Jeff Garzik]

Alan Cox wrote:
> On Iau, 2004-08-12 at 07:43, Jeff Garzik wrote:
> 
>>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.
> 
> 
> It fixes it completely on the drivers/ide driver.

SATA bus traces say otherwise.

	Jeff

Re: Any news on a higher performance sata_sil SIL_QUIRK_MOD15WRITE workaround?

[Alan Cox]

On Iau, 2004-08-12 at 16:16, Jeff Garzik wrote:
> > It fixes it completely on the drivers/ide driver.
> 
> SATA bus traces say otherwise.

Do you issue 15 or less or just combinations that are ok. With the 
siimage driver I just use the 15 limit and after hammering it hard
couldn't get it to fall over, while trying to be clever it did fall
over.

Re: Any news on a higher performance sata_sil SIL_QUIRK_MOD15WRITE workaround?

[Jeff Garzik]

On Thu, Aug 12, 2004 at 08:59:00PM +0100, Alan Cox wrote:
> On Iau, 2004-08-12 at 16:16, Jeff Garzik wrote:
> > > It fixes it completely on the drivers/ide driver.
> > 
> > SATA bus traces say otherwise.
> 
> Do you issue 15 or less or just combinations that are ok. With the 
> siimage driver I just use the 15 limit and after hammering it hard
> couldn't get it to fall over, while trying to be clever it did fall
> over.

hmmm, perhaps I misunderstood your email?

'15 or less' limit works, but 'sectors % 15 == 1' still produces odd
Data FIS sizes that confuse Seagate drives.

I thought you were saying that 'sectors % 15 == 1' was OK.

	Jeff

Re: Any news on a higher performance sata_sil SIL_QUIRK_MOD15WRITE workaround?

[Alan Cox]

On Iau, 2004-08-12 at 22:03, Jeff Garzik wrote:
> '15 or less' limit works, but 'sectors % 15 == 1' still produces odd
> Data FIS sizes that confuse Seagate drives.
> 
> I thought you were saying that 'sectors % 15 == 1' was OK.

Only the subset of use I tried in siimage. Thats the 15 or less limit on
the specific list of seagate drives affected. 

Re: Any news on a higher performance sata_sil SIL_QUIRK_MOD15WRITE workaround?

[Clem Taylor]

Jeff Garzik wrote:
> Get a different controller + disk combination.

I don't want to dump the disks, but I may be ordering a 3ware controller 
in the near future. The only reason I didn't get a 3ware controller in 
the first place was that the Sil 3114 was on the motherboard.

> 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.

I thought that the Seagate ST3160023AS was a fairly new drive. I noticed 
a comment that version 3.18 of the firmware may not suffer from this 
problem, can anyone confirm this? I'm going to try removing my drive 
from the blacklist and see what happens.

>> 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 :)

I tried, my contact at Seagate doesn't seem to be with them anymore (I 
haven't worked in the storage space in quite some time).

                 Thanks for the help,
                 Clem

Re: Any news on a higher performance sata_sil SIL_QUIRK_MOD15WRITE workaround?

[Alan Cox]

On Gwe, 2004-08-13 at 05:18, Clem Taylor wrote:
> I tried, my contact at Seagate doesn't seem to be with them anymore (I 
> haven't worked in the storage space in quite some time).

I was told the affected drive list was non-disclosure. At that point I
got bored of playing the game.

Re: Re: Any news on a higher performance sata_sil SIL_QUIRK_MOD15WRITE workaround?

[Eric Mudama]

I'm not sure about "affected" drives, but the issue as Jeff pointed
out is that SI3112/3114 send write data to the host in non-multiples
of 512 bytes, if the command exceeds 15 LBAs in size.

Up to 15*512 bytes gives you a single FIS of 15*512, for anything
larger they have an internal algorithm that is pretty easy to figure
out with a bus trace.

To work with drives that aren't capable of handling this, you can't
issue writes > 15 LBAs to the drive, hence the blacklist/workaround.

--eric