Date: Fri, 10 Jan 1997 14:15:41 -0800 From: Ken Ingram <kingram@ipro.com> To: Terry Lambert <terry@lambert.org> Cc: joerg_wunsch@uriah.heep.sax.de, FreeBSD-current@freebsd.org Subject: Re: Adding Hard Drives - Prepping Message-ID: <199701102208.OAA02511@ipro.com>
next in thread | raw e-mail | index | archive | help
This was an excellent explanation. I feel a bit more knowledgable on the whole. Thanks At 02:06 PM 1/10/97 -0700, Terry Lambert wrote: >> 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. > > --Ken ________________________________________________________________________ Ken Ingram kingram@ipro.com | ------------------------------------------------------------------------ POST NO BILLS
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199701102208.OAA02511>