Subject: Re: VPS mailing list, BSD interest?
To: Kevin P. Neal <firstname.lastname@example.org>
From: Terry Lambert <email@example.com>
Date: 09/29/1996 14:58:20
> 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 (firstname.lastname@example.org) 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
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).
Any opinions in this posting are my own and not those of my present
or previous employers.