Date: Fri, 10 Jan 1997 14:06:48 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: kingram@ipro.com (Ken Ingram) Cc: joerg_wunsch@uriah.heep.sax.de, FreeBSD-current@freebsd.org Subject: Re: Adding Hard Drives - Prepping Message-ID: <199701102106.OAA20554@phaeton.artisoft.com> In-Reply-To: <199701101925.LAA25150@ipro.com> from "Ken Ingram" at Jan 10, 97 11:32:31 am
next in thread | previous in thread | raw e-mail | index | archive | help
> I understand slices,partitions,filesystems and mounting. In fact the > histrionics I've gone through to simply add 1Gb to a newsserver has > been quite instructional I will actually have something to contribute . when all is said and done. > > Is devfs something about 'device file system' or something thereabout? Yes. When a device is probed true, a device node is created for it automatically in a devfs implementation. There are no device nodes for non-existant devices. There are no incorrect device nodes. If you disallow symlinks, there are no broken links. Unfortunately, devfs alone is not sufficient to level all of the obstacles you personally ran into... what is still missing from the current implementation is called a physical to logical translation layer. --- Physical to logical translation layers, simplified --- When a device is probed true, it "arrives" in the knowledge of the system. Let us say for example that /dev/dsk/wd0 "arrives". When this happens, it is possible to examine the device as a result of this "arrival event". This examination is done by running a list of available "physical to logical translation layer" probes against the device. Typically, the probles will read the first sector of the device to determine if partitioning is present. If partitioning is present, then the physical to logical device attach occurs. For example, say the "DOS partitioning physical to logical mappping" probe came true. The attach routine for the layer determines that the DOS partition table contains two valid partitions, P0 and P2. The attach routine reenters the interface -- two more "arrival events" occur. Let us say they are for "/dev/dsk/wd0/p0" and "/dev/dsk/wd0/p2". Say "/dev/dsk/wd0/p0" (the first DOS partition on the disk device wd0) contains a BSD disklabel. So again, we have partitioning present; this time the "BSD disklabel physical to logical mapping" probe comes true. The attach routine for the layer determies that the BSD disklabel contains four valid partitions, a, b, c, and d (note that c and d are real partitions. Because we can reference the "whole disk" via /dev/dsk/wd0 and the "whole BSD area" via /dev/dsk/wd0/p0, we no longer need to steal c and d for these purposes). The attach routine reenters the interface -- four more "arrival events" occur. Let us say they are for "/dev/dsk/wd0/p0/a", "/dev/dsk/wd0/p0/b", "/dev/dsk/wd0/p0/c", and "/dev/dsk/wd0/p0/d". Say that b is swap, and the rest are file systems... that is, there is no more partitioning present. We must also get an "arrival" for "/dev/dsk/wd0/p2"; say it contains a VFAT (DOS) filesystem. In point of fact, CCD devices can "arrive" and be accumulated until they are all present the same way (at which time a "/dev/dsk/ccd0" would itself "arrive"). And so on. It works for device agregation, partitioning, and even for media perfection (an error revocery layer, like BAD144, could be applied to any device, exactly the same way). --- Magic --- We have device arrival events for the following "terminal" devices: "/dev/dsk/wd0/p2" "/dev/dsk/wd0/p0/a" "/dev/dsk/wd0/p0/b" "/dev/dsk/wd0/p0/c" "/dev/dsk/wd0/p0/d" We can say we are done here... or... We can handle any unclaimed (by physical to logical layering) device arrival as a *filesystem* arrival. This assumes the mount routines will fail silently without noise on the mount atempt, and that the mount hierarchy insertion is logically seperate from the physical mount operation where the mount structure is filled out. In simple terms, we move mount point covering out of the VFS code, and each resource is mounted as if it were it's own root device. This incidently, as a side effect, greatly simplifies a lot of code, and makes any new FS more likely to be robust in the face of things like vnode locking, NFS exports, and all of the things which are common to FS implementations at the VFS consumer level, but which are currently implemented in each and every FS implementation... it makes the common code common, like it should have been in the first place. In concept, it's similar to unbottoning your bellybutton... you have to watch that your butt doesn't fall off. ;-). IFF we do this, then we can automount drives at arrival. Since CDROMs, docking station drives, network drives in the case of transient net connectivity, and PCMCIA cards can all "arrive" after a system is up, we can make these resources available *automatically* and *transparently*. > And truly, what does knolwedge of partitions, &tc. have to do with making a > standard. I still would need that info now if things had been easier. Logically, it doesn't have dick to o with it. In the current implementation, a lot of wires are exposed; they are used in a uniform, predictable, and therfore unifiable way, but they have not been abstracted. That is one of the promises of devfs. > As it stands I got what I was looking for: a rather intense intro > to 'Adding Hard Drives - Prepping' Unfortunately, as I have been trying to point out, a number of us want desperately to make that information useless, as soon as we possibly can. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199701102106.OAA20554>