Date: Sat, 13 Dec 1997 21:51:26 +1030 From: Mike Smith <mike@smith.net.au> To: bgingery@gtcs.com Cc: hackers@FreeBSD.ORG Subject: Re: blocksize on devfs entries (and related) Message-ID: <199712131121.VAA02610@word.smith.net.au> In-Reply-To: Your message of "Sat, 13 Dec 1997 04:02:08 PDT." <199712131102.EAA20340@home.gtcs.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> Now, the physical layout is (at least theoretically) pollable for > some devices. What I'm saying is don't throw away the POSSIBILITY > of storing and using this information in an orderly way. I'm quite happy with the concept of passing some information up, but very cagey about what is actually useful. Physical layout is almost useless in that there is no useful standard for its presentation, and no easy method for making it consistently available. Consider an example; we have a filesystem that wants to optimise its on-disk layout to take advantage of the physical parameters of the disk on which its filesystem lives. How will it lose, let me count the ways... - You can't extract meaningful disk geometry data from a ZBR disk. - You can't devise a measurement process to determine various basic timing parameters of a modern disk as these are nondeterministic. - If the filesystem is presented with a synthetic extent spanning several different disk devices, which set of nonexistent parameters would you be supplying to the filesystem? Just three off the top of my head. There are probably more. As I said, there are some basic qualitative parameters that you could attach to an extent. You would have to supply a "combination" function that would produce a single value out given a set of values in (for producing a summary value for a synthetic extent), and possibly a "separation" function (for producing a single value for a region of an extent). This sounds like a great deal of work for what currently appears to be a pretty mythical benefit. 8) > -} The RO->RW upgrade notification is a contentious issue, but one that > -} definitely needs thinking through. How would you suggest it be > -} handled? Should the standard be to reopen the device, or pass a > -} special ioctl, or add a new device entrypoint? > > To me, an IOCTL and flag would be tighter than different entry > points for ro vs rw. Not necessarily tighter code, but tighter > management. How would you reject the ioctl? (FWIW, I am inclined to agree that overloading the ioctl interface is the "best" approach here, if not the most architecturally clean.) Bear in mind that an unknown ioctl will usually return ENOTTY or similar; you would have to specify an explicit return value for rejected upgrades. > -} > Yet, why deny these the optimization information which will allow > -} > them to map (within the constraints of their architecture) a new > -} > filesystem for best throughput, if it's actually available. > -} > -} Because any "optimisation information" that you could pass them would > -} be wrong. Any optimisation attempting to operate based on incorrect > -} parameters can only be a pessimisation. > > Why must it be wrong? Because it cannot be guaranteed to be correct if it is present. I tell you that one glass contains deadly iocaine powder, and the other does not, and you drink from the latter. Then I tell you that both are poisoned. Your optimisation for life has failed, despite making the correct choice based on the available facts. > -} > Now let me raise some additional questions -- > -} > > -} > > -} > Should a DASD be mappable ONLY with horizontal slices? ... > -} This is a nonsense question in the context of ZBR and "logical extent" > -} devices (eg. SCSI, ATAPI, most ATA devices). > > Okay, but not those which expose that info and allow direct > control. Across the Free *n?x lines we're seeing more and more > antique resurrections - even if that's the ONLY place this could > be used accurately. As the owner of a not inconsiderable number of such antiques, I can tell you that non-ZBR devices are in an extreme minority, and those that haven't yet bitten the dust are well on their way. In the case of a new model design, attempting support for a microscopically small and ever-shrinking portion of the potential platform base given the relative costs involved is just not practical. mike
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199712131121.VAA02610>