Date: Mon, 24 Jul 2000 16:34:40 -0700 (PDT) From: Matthew Jacob <mjacob@feral.com> To: Jack Rusher <jar@integratus.com> Cc: freebsd-arch@FreeBSD.ORG Subject: Re: SANs, disks, & devfs Message-ID: <Pine.BSF.4.05.10007241629460.15581-100000@semuta.feral.com> In-Reply-To: <397CBF31.BABAB0F8@integratus.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> This seems perfectly sensible. I am interested to see if there will > be some method to give a common access method (excuse the pin) that > solves both sets of requirements (abstract and direct). This is one of > the areas in which FreeBSD can really step ahead of the other server > OSs. Yes, that's the idea there... :-) > > physical, while /dev names would be logical. I argued that /dev/sd[0..n] was > > perfectly adequate in this model (rather than trying to encode position > > information into the name as the /dev/[r]dsk names do). Furthermore, naming > > The c0d0t0s0 naming convention is a funny idea, I agree. It is sort > of worst of both worlds. :-) To quote Le Carre: "It was such a dull monument to such long and dreary war". > > > disks (at least) by volume name (the "Fred" volume) is even more convenient. > > This is a nice feature. Do we want all three things (physical, > logical, and name) as potential disk ids? If so, how do you tell the > tools which name space you are working in? Some sort of accesor > character before the "name"? Search order? What about duplicates (i.e. > someone names the disk "sd0")? Umm- that's the user's lookout, frankly. When you get to this level, you start to need a volume management GUI (and as someone who despises GUIs, it costs me dear to say that....) > > > I'd much rather see some framework in FreeBSD (and NetBSD and OpenBSD.... > > Linux has a devfs going...) to accomodate this. But that isn't there yet and > > won't be for a while. I want to solve this for 5.0 for sure. > > Some of the implementation details of the JINI model are pretty > hairy. It would be pretty wasteful if that stuff had to end up in every > driver. :-; > Something else that I would like to see done with devfs and procfs in > the future of FreeBSD is the ability to unify these namespaces over > several machines. There was some really good work done at SunLabs for a > thing called Solaris MC that allowed single system image over a set of > machines. They used a networked version of the ddi/devfs facility and > added vprocs to the proc structure to allow one machine to address the > processes and devices on another. This leads to some very nice parallel > computation, load balancing, and HA implications. Yes. But I'd like to solve the other problems first! ;-) -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.05.10007241629460.15581-100000>