Any news on a higher performance sata_sil SIL_QUIRK_MOD15WRITE workaround?

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

Get a different controller + disk combination.

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.

You could find out for us, and let us know :)

Jeff

It fixes it completely on the drivers/ide driver.

SATA bus traces say otherwise.

Jeff

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

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.

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

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.

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.

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

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

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