* [parisc-linux] Re: 53c700: tagged queueing problem confirmed [not found] <200110220034.f9M0YM701447@localhost.localdomain> @ 2001-10-23 20:33 ` Daniel Engstrom 2001-10-23 23:59 ` James Bottomley 0 siblings, 1 reply; 3+ messages in thread From: Daniel Engstrom @ 2001-10-23 20:33 UTC (permalink / raw) To: James Bottomley; +Cc: Daniel Engstrom, parisc-linux, Richard Hirst On 2001.10.22 02:34 James Bottomley wrote: > 5116@telia.com said: > > I have investigated this some more and I have come to the conclustion > > that you are quite right. I disabled tagged queueing in the drivber > > and it instantly bacame stable. > > > Do you have any idea on how to proceed debugging this? > > Well here's my theory: > > There are a number of reports with tag command queueing problems > associated with these drives. In particular, one for freebsd said > that the aic7xxx driver was reporting data overruns with TCQ enabled > on Quantum Fireballs. Ok. I have used these drives with i386 Linux without problems with both the aix7xxx driver and the sym53c8xx driver. Both these drivers use a default of max 8 tags per lun, so I chnaged the value in your driver and it works. So, maybe 8 tags per lun is the conservative default here ? /Daneil -- ^ permalink raw reply [flat|nested] 3+ messages in thread
* [parisc-linux] Re: 53c700: tagged queueing problem confirmed 2001-10-23 20:33 ` [parisc-linux] Re: 53c700: tagged queueing problem confirmed Daniel Engstrom @ 2001-10-23 23:59 ` James Bottomley 2001-10-24 3:38 ` Grant Grundler 0 siblings, 1 reply; 3+ messages in thread From: James Bottomley @ 2001-10-23 23:59 UTC (permalink / raw) To: Daniel Engstrom; +Cc: James Bottomley, parisc-linux, Richard Hirst 5116@telia.com said: > I have used these drives with i386 Linux without problems with both > the aix7xxx driver and the sym53c8xx driver. Both these drivers use a > default of max 8 tags per lun, so I chnaged the value in your driver > and it works. So, maybe 8 tags per lun is the conservative default > here ? That's not unreasonable. You're going to run into problems with the new aic7xxx driver, though, which has a default of 253 tags. Usually you want larger numbers of tags to allow multiple active I/Os and give the device the most freedom to order them efficiently. However, in linux we have the elevator to consider as well: The more tags, the less time the I/Os spend in the elevator queue and the less chance of coalescing adjacent I/O. For any given workload, there's probably an optimal tag number and I bet they cluster around some value for a variety of workloads, but I've no idea what it is. I'd still be wary of allowing tags on this drive. The firmware clearly has a point beyond which it goes haywire and you don't really know where that is. It could be that reducing the max tags to 8 makes this unlikely but not impossible, so you may still end up with insidious data corruption possibilities. James ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [parisc-linux] Re: 53c700: tagged queueing problem confirmed 2001-10-23 23:59 ` James Bottomley @ 2001-10-24 3:38 ` Grant Grundler 0 siblings, 0 replies; 3+ messages in thread From: Grant Grundler @ 2001-10-24 3:38 UTC (permalink / raw) To: James Bottomley; +Cc: Daniel Engstrom, parisc-linux James Bottomley wrote: > That's not unreasonable. You're going to run into problems with the new > aic7xxx driver, though, which has a default of 253 tags. > > Usually you want larger numbers of tags to allow multiple active I/Os > and give the device the most freedom to order them efficiently. Hmm...not really. Maybe for DOS or other really stupid OS's. > However, in linux we have the elevator to consider as well: The > more tags, the less time the I/Os spend in the elevator queue and > the less chance of coalescing adjacent I/O. That's right...coalescing and seek times need to be considered. WCE bit (that I described before) also affects how long IO are on the disk sort queue. With WCE enabled, setting the max number of tags to 2 (or so) works very nicely. I'm told Linux's disk sort elevator isn't very good about starvation. ie IO's can get "prempted" for a long time because the IO is destined for a currently "out of favor" geography on the disk. One more consideration unique to multi-initiator SCSI clusters: (Ie several hosts share devices on one SCSI bus) The total number of outstanding IO can't exceed what the disk is capable of handling or we end up wasting bandwidth to requeue rejected IO's (BUSY msg or something like that). > For any given workload, there's probably an optimal tag number and I bet > they cluster around some value for a variety of workloads, but I've no > idea what it is. 8 tags seems to be a pretty good trade off between on-disk optimizations and OS trade-offs for database apps. At least that was true a few years ago. > I'd still be wary of allowing tags on this drive. The firmware clearly has a > point beyond which it goes haywire and you don't really know where that is. > It could be that reducing the max tags to 8 makes this unlikely but not > impossible, so you may still end up with insidious data corruption > possibilities. Check with the vendor to see if the firmware is upgradeable. Odds are if someone like HP or Sun is OEM'ing the disk, bugs in the firmware have been found and fixed in later versions. grant ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2001-10-24 3:42 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <200110220034.f9M0YM701447@localhost.localdomain>
2001-10-23 20:33 ` [parisc-linux] Re: 53c700: tagged queueing problem confirmed Daniel Engstrom
2001-10-23 23:59 ` James Bottomley
2001-10-24 3:38 ` Grant Grundler
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.