[illumos-Developer] Changing sd_io_time to 8?

[Garrett D'Amore]

On Tue, 2011-05-03 at 21:55 -0500, Mike La Spina wrote:
> From the risk flags put up on the sd_io_time modification, would it be
> prudent to just use the dreaded sd.conf tunable? Yes I know, not another
> one of those arcane tuning parms that nobody can recall and set without
> reading source. However sd does have a man page to hold this info .....
> it's not a great solution but when correctly targeted it does prevent
> some ugly slow hardware recovery scenarios with JBODs that many people
> curse at. (myself included)

I think we can be smarter here too.

CDROMS need a longer recovery time.

Disks on Parallel SCSI might need longer.

Disks on fibre, SAS, and SATA, should all respond within a narrow window
of time unless something is seriously amiss.

Virtual disks are a crapshoot... I'd set the timeout high for them.

SD can already detect each of these scenarios.  We just need to code it
up.

That doesn't mean we can't make it a *cough* tunable.  But tunables
should have reasonable (good?) default settings.

	- Garrett

> 
> 
> -----Original Message-----
> From: Garrett D'Amore [mailto:garrett at nexenta.com] 
> Sent: Tuesday, May 03, 2011 11:48 AM
> To: Dan McDonald
> Cc: developer at lists.illumos.org
> Subject: Re: [illumos-Developer] Changing sd_io_time to 8?
> 
> On Tue, 2011-05-03 at 12:32 -0400, Dan McDonald wrote:
> > On Tue, May 03, 2011 at 05:22:32PM +0100, Deano wrote:
> > 
> > <SNIP!>
> > 
> > > It is exactly this kind of confusion, which is why I believe why SD
> is
> > > overburdened, also from the source code which at IIRC 13K+ LOC is
> well
> > > above most software engineering thoughts on file size indicates it
> to me.
> > 
> > Well SOMETHING had to take the place of ip.c as biggest source file in
> the
> > kernel.  ;)
> 
> Oh, I can probably think of several bigger files, and certainly bigger
> *drivers*.
> 
> None of which means this is a good example to follow.  There is no
> reason that sd should be more than about 5 or 6KLOC -- except that it is
> filled with logic for too many different types of devices, and to deal
> with too many exceptions.
> 
> I've contemplated a major overhaul of this driver in the past.
> 
> If nothing else, the tunable mechanism is so arcanely byzantine, that
> nobody can reasonably use it without spending time reading the code --
> yet there are a significant number of things in that driver that you
> really *do* want to tune for different types of devices.
> 
> 	- Garrett
> > 
> > Dan
> > 
> > _______________________________________________
> > Developer mailing list
> > Developer at lists.illumos.org
> > http://lists.illumos.org/m/listinfo/developer
> 
> 
> 
> _______________________________________________
> Developer mailing list
> Developer at lists.illumos.org
> http://lists.illumos.org/m/listinfo/developer