forks,albod,resources,etc. Code! (Not for 2.4!)

["James M. Mills" <wanderer@ipinc.net>]

[-- Attachment #1: Type: text/plain, Size: 2946 bytes --]

    Code at last! The attached patch may be applied against 2.3.12 and
at
some point worked against versions back to 2.3.7 I believe. I don't know
if
it still works against older versions.

    This is x86 and Ext2 specific! I have made no provisions for other
platforms as I have no way to check them. Better to leave it to the
experts. Most of the changes are in VFS code, but there are a few
changes
in Ext2 code. Note that Remy has not approved these changes! Other file
systems should be able to implement the needed changes, but again the
experts need to dirty their fingers.

    This is a first review patch. No one has seen it but myself --- that
is
a warning! I need review, comment, and test by those interested and
knowledgeable. In particular, I'm concerned about dget/dput usage and
permission handling. It seems to work in a reasonable manner, but this
is a
small system and I may not be hitting the proper test cases.

    There is detailed implementation information in the patch itself.

    I originally sided with the alobd as a single file argument so that
it
could easily be copied, ftped, etc. Indeed, I started it. I was wrong.
The
alternative of a directory approach is better and is implemented here.

    Both approaches require that there be a standard, portable means of
moving metafiles between systems. With a file based approach all
accesses
have to deal with decoding/encoding this form. Originally I thought a
file
based implementation could be fairly simple. As I worked on a complete
design - removing artificial limits in my original idea - it was leading
to
a full file system on top of a file system. This could be useful for
debugging new file systems, but for initial metafiles is just plain
messy.
And potentially slow.

    Using a directory approach allows the native host system to operate
without performance penalties. In this case, the portable view need only
be
invoked when the entire metafile is exported.  Exporting is defined here
as
any access that calls for the entire metafile to be copied, moved, or
otherwise referenced.

    For even greater simplicity, the kernel only knows of one 'portable'

view - that of a directory structure! When accessed as "meta/." the
metafile is opened as a directory. Any application that can deal with a
directory can now operate on the metafile as a whole. Note that this
will
also work when a nested file system is implemented. In that case the
referenced metafile will be seen as a standard file.

    Fancy view handling may be added to the library or as a stand alone
utility. Special views may also be added in portions of the kernel such
as
NTFS. Again not an issue for this patch.

    One penalty of using a directory approach is disk space overhead.
With
a single file approach the data can be packed into smaller a space. But
this may be more rightly a file system issue. Also, the directory
approach
uses more inodes on the host file system.



[-- Attachment #2: patch-2.3.12.meta.gz --]
[-- Type: application/x-gzip, Size: 29758 bytes --]

[-- Attachment #3: libmeta.0.0.1.tgz --]
[-- Type: application/octet-stream, Size: 3815 bytes --]