Date: Sat, 13 Dec 1997 21:28:25 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: julian@whistle.com (Julian Elischer) Cc: mike@smith.net.au, bgingery@gtcs.com, hackers@freebsd.org Subject: Re: blocksize on devfs entries (and related) Message-ID: <199712132128.OAA02173@usr06.primenet.com> In-Reply-To: <Pine.BSF.3.95.971213021310.29160D-100000@current1.whistle.com> from "Julian Elischer" at Dec 13, 97 03:05:27 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > > Theoretically, the physical layout of the device should be stored > > > whether or not there's any filesystem on it. > > The problem is that on all new devices the layout is both hidden and > not easily describable. Nor can we describe the layouts of media that have > not yet been invented. Track/cyl/sector geometry descriptions can not be > used to describe modern disks and the picture is muddied by track buffers > and reverse block write order (for example). SCSI I geometries are not directly accessable. But SCSI II geometries are. I think track buffers and reverse block write order are attributes that could be communicated (actually, the second implies the first. 8-)). [ ... ] > In the face of confusion, do nothing.. > I will probably punt on must of the complicated issues, believing that > the drive manufacturers will just do the best they can :) This is a good approach. The cylinder seek optimizations in the face of no knowledge of the disk layout are actually pessimizations. But if you *do* have knowledge of the disk layout... > r/w 'openness' is and should be propogated up and down. I've already > started work on this. The difficult bit is not in the SLICE code, but > rather in teh existing system code that doesn't notify the slice code when > this happens. This is where Poul's suggestions about needing explicit events on open/close come into play. It's so blatantly obvious (after Poul pointed it out, of course ;-)), that it's strange that we are still talking about it. > Manufacturers will be making devices to be optimised to do what we want > to do. so for us to try do something different may even slow things down. This is signaturable, Julian. 8-). I can imagine my static column DRAM from my other post arranging access to a large number of columns simultaneously. Going outside this locality to another column would be a large penalty, on the order of a seek delay (given the relative speed of SRAM vis-a-vis disk transfer rate relative to disk seek time). > DEVFS is PRIMARILY for non DASD devices.. I have only added the DASD > support in the last month. Another example of what someone might want is clonable devices; tunnel devices, BPF devices, etc.. Pty's are just the most obvious type of clonable device, not the only ones of interest. I can see a definite need for device-as-directy-containing-devices. This speaks once again in favor of Poul's discrete reference notifications. > The outwards appearance of no change, but an internal complete rebuild to > be more modular. Sounds exactly like some FS changes someone was pushing for a while back. }B-). One aspect of devfs that no one has been pushing to hard, but which I think should be mentioned is the fact that, currently, it is impossible to netboot a FreeBSD machine off of some types of host systems that are unable to represent FreeBSD's devices. DEC UNIX is one example. By making the devices intrinsic to the kernel instead of represented externally by type+major+minor, the devices are not dependent on any external storage for their existance, so external storage limitations no longer apply (like this one; there are others). This also makes it easier to get an initial port going, since there is no need for an NFS -or- local media FS in order to get a minimal single user shell... 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?199712132128.OAA02173>