Date: Wed, 3 Apr 1996 12:59:21 +0930 (CST) From: Michael Smith <msmith@atrad.adelaide.edu.au> To: Brett_Glass@ccgate.infoworld.com (Brett Glass) Cc: msmith@atrad.adelaide.edu.au, jkh@time.cdrom.com, hardware@freebsd.org Subject: Re: Some solutions to disk problems.... I think. Message-ID: <199604030329.MAA18024@genesis.atrad.adelaide.edu.au> In-Reply-To: <9603028284.AA828461240@ccgate.infoworld.com> from "Brett Glass" at Apr 2, 96 08:30:30 am
next in thread | previous in thread | raw e-mail | index | archive | help
Brett Glass stands accused of saying: > > > Timeouts should default to off, in order to deal with problems like > > yours. > > I'm not so sure. Pity the poor laptop owner whose drive spins up relatively > quickly (so that turning off the timeout isn't absolutely necessary). He > installs FreeBSD, and suddenly finds his batteries completely discharged! > The mailing lists receive dozens of complaints, and FreeBSD becomes known > as a notebook power hog. *shrug* The alternative is complaints like yours, where FreeBSD becomes known as a pedant for on-the-spec behaviour. The difference is that what I'm talking about is identifying _specific_ drives that behave in unfriendly fashions, and dealing with them to solve the _specific_ problems that they cause. > > The rogues table would also be able to indicate to ioctl code > > that wanted to reenable power-saving modes that the disk required special > > handling. > > In other words, you'd want to create a "power saving" ioctl? I'd suggest an ioctl that controlled the power mode of the drive. The spec implies that it should be possible to punt the drive into and out of various modes; the rogues table would allow for drives which required nonstandard methods for this process. > > The flagspace is too small. > > In this case, it's easy to enlarge. Just expose per-drive flags as well as > per-controller flags. That's not possible; the drives aren't visible until after they're probed, and userconfig already knows too much about the innards of the system. > > That's not so crash hot. Use a table with a list of drive ID responses > > and flags which define quirks; it's not just at attach time that oddities > > may have to be worked around. > > A table would not cover all the contingencies. Each manufacturer has its > own way of creating model numbers for products. Some put letters at the > beginning; some at the end. Some have, over time, switched the letters from > the end to the beginning or vice versa. (Maxtor, for example, moved the > letters from the end to the beginning, then added more at the end again.) > Some have hyphens in the model numbers (or have added or removed them over > time). A simple wildcard matching routine would handle this sort of thing. > Some have dozens of models that act similarly; there's no need to > bloat the table by adding every one. Some have even changed their > numbering systems during mergers and acquisitions. A cascade of routines > that both recognize ID strings and act on the relevant devices is, in my > experience, the most efficient and elegant solution. If one tries to > implement a table, one winds up having to include recognition code anyway; > the table becomes a waste of space. The excess of functions duplicating essentially the same functionality makes it very difficult to see, at a glance, what is being searched for. A table summarises everything in one place, and avoids the common case where total duplication occurs because the new patch isn't immediately recognised as doing the same thing as another that's been overlooked. I guess I'm pointing at prior art (all of the SCSI rogue detection code I've ever seen in operating systems), and saying "this works. They're probably smarter than either me or you, so let's do it the same way" 8) > --Brett -- ]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ ]] Genesis Software genesis@atrad.adelaide.edu.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control (ph/fax) +61-8-267-3039 [[ ]] Collector of old Unix hardware. "Where are your PEZ?" The Tick [[
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199604030329.MAA18024>