Date: Thu, 16 Oct 2008 02:56:08 -0700 From: Jeremy Chadwick <koitsu@FreeBSD.org> To: "Andrey V. Elsukov" <bu7cher@yandex.ru> Cc: freebsd-stable@freebsd.org, kib@freebsd.org, sos@freebsd.org Subject: Re: Request for testing: ata(4) MFC Message-ID: <20081016095608.GA5861@icarus.home.lan> In-Reply-To: <48F70642.7080701@yandex.ru> References: <676151223134689@webmail38.yandex.ru> <20081005004808.GA70137@icarus.home.lan> <48E99C18.6070602@yandex.ru> <20081006051211.GA10542@icarus.home.lan> <20081010115855.GA31707@icarus.home.lan> <20081016071700.GA2793@icarus.home.lan> <48F70642.7080701@yandex.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Oct 16, 2008 at 01:15:46PM +0400, Andrey V. Elsukov wrote: >> - Can we please see about adding the FreeNAS project's ata timeout >> sysctls? I see lots of delays/sleeps in numerous pieces of code that >> pertain to soft or hard resets of AHCI controllers, and I often worry >> about the implications of hard-coded timeouts. >> >> http://freenas.svn.sourceforge.net/viewvc/freenas/trunk/build/kernel-patches/ata/files/patch-ata.diff?view=markup > > As i remember changes in FreeNAS don't change timeouts for resets. You're quite right -- they define the allowed time between the moment the OS sends a command to the device/disk to the time the device/disk sends back an OK/response. The point is that all these timeouts (well, not every single one, but the obvious ones) should be sysctl adjustables. I worry that too strict a timeout could cause the device/controller to be inappropriately reset during times when a disk may be doing something internally (such was the case with old IBM disks and their ADM feature; true, the feature is no longer implemented, but you get the point), and I also worry that too loose of a timeout might cause the system to lock up for long durations of time when a controller reset actually is needed. The default values we have are fine, but letting people tune them based on their system would be ideal. The FreeNAS guys have already provided evidence that tuning such variables is beneficial for some users, depending upon the type of disk and bus they're using. > In any case, these changes can not be in 7.1-RELEASE. My patch > targeted to move changes from CURRENT to 7.1. But it seems there > are too few testers and patch can not be commited. This doesn't bode well. :-( I think the problem is: 1) Not a lot of people have "dev boxes" they can try this stuff out on, (Personally, I do have such boxes, but I don't have physical access to them (I would have to go to our datacenter) to try failure scenarios; "general" usability testing I can do of course), 2) Very few (if any at all) are willing to put the patch on a production machine, as the risks outweigh the benefits for most, 3) Lack of eyeballs -- I have no idea how many FreeBSD users are subscribed to -stable, and of those, how many use ATA or even care about the patch ("my stuff works, why would I want to try this?") Are we hoping that the patch will be included in 7.2? -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB |
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20081016095608.GA5861>