Date: Sat, 13 Dec 1997 22:08:40 +1030 From: Mike Smith <mike@smith.net.au> To: Julian Elischer <julian@whistle.com> Cc: Mike Smith <mike@smith.net.au>, bgingery@gtcs.com, hackers@FreeBSD.ORG Subject: Re: blocksize on devfs entries (and related) Message-ID: <199712131138.WAA02658@word.smith.net.au> In-Reply-To: Your message of "Sat, 13 Dec 1997 03:05:27 -0800." <Pine.BSF.3.95.971213021310.29160D-100000@current1.whistle.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > In my slice code I propogate blocksize up. Each layer can make the > decision as to what blocksize it wishes to export further up. A disk array > would probably export a blocksize equal to the largest blocksize of it's > component parts. Just checking the obvious; the blocksize of potential components is available to the layer(s) above at attach time, so that they can reject them at that point? > I might also propogate up a maximum acceptible chunk, and an optimal one, > but how to interpolate these at higher layers becomes non-solvable without > breaking layering. (or by preceding every IO call with a callthat asks > "If I were to do IO to location X how big would you like it to be?") > This is not an answer. No. I was considering a proposal whereby a layer could not propagate upwards a blocksize less than the largest of its inferiors, but that's clearly pointless. The idea of passing a "recommended chunk size" up would be good though; a multiplexing layer could use that to break requests from above up into optimal chunks for layers below. Likewise the maximal chunk number. > > > 2. physical layout (sect/track, tracks/cyl) also needs to > > > be stored for any DASD. Also any OTHER known info which > > > may be used to optimize the filesystem building process for > > > the device, such as rotational speed, seek timing .. If > > > this is not stored with driver info in the devfs, then > > > some pointer or common reference point should be made to > > > the "file entry" that contains the info. > > > > Physical layout is a joke, and has been for many years. This > > suggestion costs you a lot of credibility. > > Some of this information will be available by asking for a disklabel > struct from any slice. > fields such as RPM will be propogated up from the device(s) if possible > where fields such as drive size are reflections of that particular slice. Can I perhaps argue for the rapid death of the disklabel structure (other than in a hypothetical compatability layer)? It's an obscenity that's long overdue for death. I've fought the "fake a disklabel that's acceptable to all consumers" battle several times (losing more often than winning), and seeing it go forever would be Very Pleasant. Yes, I realise that it's cast in domains on disk, and perhaps unlikely to change there, I just ask that it be abandoned as a means of describing the characteristics of a disk (extent) and the (conceptually indirectly related) set of partitions contained in that extent. > > This is not useful. An upper layer should not care whether the extent > > it is consuming is a concatenation of extents. This is an issue for > > management tools, which should have an OOB technique for recovering > > structure information. > As Mike says, The whole aim of the slice layers and related things is to > HIDE this.. In earlier email you indicated that you thought I should make > nodes in the devfs, in parallel to the device nodes, that DESCRIBED > the devices.. Are you referring to me or Brian? We discussed this at one stage, but I think the consensus was that the correct approach was for anything that was interested in the construction of an extent to traverse the extent's inferiors working it out for itself. I'm aggro; my test box is at work, and I'm waiting for a call to go to a party. I wanna be playing with this stuff now the IDE code should be working. 8) Now, if someone could write an NCR driver for the CAM code... mike
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199712131138.WAA02658>