Date: Sun, 29 Sep 1996 14:58:20 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: kpneal@pobox.com (Kevin P. Neal) Cc: current-users@netbsd.org, hackers@FreeBSD.org, tech@openbsd.org Subject: Re: VPS mailing list, BSD interest? Message-ID: <199609292158.OAA04652@phaeton.artisoft.com> In-Reply-To: <1.5.4.32.19960928233700.0087ad8c@mindspring.com> from "Kevin P. Neal" at Sep 28, 96 07:37:00 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> Ok, my friend Chris Dukes wants a LVM-like thing for a free Unix. He's working > with the Linux guys on creating one fairly similar to the one found on AIX. > > The question is, is anybody in the BSD world interested in such a thing? It > would allow lots of neat things, like extendable partitions. Mirroring > of logical partitions, etc. > > I'm very sure that they would like help with their project, and if some *BSD > guys get involved with it, issues for us would be diminished (with respect to > re-using their code in our kernels). > > Is anybody interested? If so, email Chris Dukes (cddukes@eos.ncsu.edu) and > let him know. Signing up on the mailing list would be a nice bonus as well. > Chris is doing lots of design work now. I have alpha grade logical volume management code for devfs using physical-to-logical and logical-to-logical device mapping. I am convinced that device mapping is the place to do this, so the AIX stuff is comparatively primitive in implementation (though it has a nice user interface). I think that there is no way to extend the FFS or EXT2 FS areas in a reasonable way using PP agregation as in AIX; I suspect you will need an FS that knows about volume extension through logical device agregation (JFS can do this; NTFS can do this as well). For FFS, you could consider etending from a single to multiple cylinder groups, and not the fragmentation problems that *must* result from incrementally growing the FS area. I happen to have a read-only JFS working (which I did for AIX binary compatability with the Motorolla Ultra 603/604 [PowerStack] PPC motherboard). I haven't done an NTFS because I am aware of another project in that direction, and because I has a JFS available for testing, but no NTFS, at the time. My JFS requires some significant changes to the BSD VFS/VOP interface framework to function; the only reason it isn't writeable is that I haven't bothered to write the code for it. The Linux NTFS is probably unsuitable to solve the problem of using agregate PP-based devices because the Linux VFS framework has a number of basic structural incompatabilities with ordered updated (journalling requires that you consider the FS as a series of events and handlers for events, so making the NTFS read/write or implementing a JFS under Linux wants some stronger ordering guarantess than the FS/buffer cache interaction currently allows under Linux). Lest you think I haven't studied the Linux code enough to have an opinion, it was me who submitted the patches for the memory leak in the path lookup failure case about a year ago (I submitted them through Matt Day, who sent them to Linus). I also submitted a number of fixes the Udo Walther's (sp?) UMSDOS code (mostly adding things like DOS locking semantics for clients of the FS which export the FS via Samba or other file server technology to DOS/Windows client machines). I also submitted fixes for the path conversion code to make it more generic, since the current code can't handle importing NFS paths for a kernel-based NFS (it can only import path strings, and isn't a generic copyinstr, like in BSD, and there are a number of race conditions having to do with a blocking operating following buffer validation but before buffer usage -- a generic problem with buffer prevalidation, actually). Has there been any consideration of adopting the Heidemann/Ficus framework for VFS in Linux, like in BSD? John considered most of these issues in his initial design, even though the current BSD 4.4 integration disables much of the intended flexibility (ie: the Ficus framework was basically "pounded into" the BSD 4.4 code as an emergency reaction to the USL file list). 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?199609292158.OAA04652>