Greetings.
I just picked up the "cow-links" thread and it interested me, as
I have been doing some thoughs parallel to this. Unfortunately,
my current knowledge and time contraints limit my kernel learning
and work to squeezing it in between my textbooks.
I think the cow-links and the versioning filesystem are all
complementary ideas. While working with Star Office on a Solaris
system, my primary job was to limit user disk space usage, as it
was quickly prohibitive. I thought of a "Copy-on-write" filesystem
which would allow users to simply mount a global template filesystem
over top of their home staroffice directory. Unfortunately, with
many thousands of users, it was quickly prohibitive to actually
mount each filesystem, not to mention various secuity concerns.
The basic idea that, if I read this correctly, the ideas have in
common is to conserve disk space by allowing either file-level or
filesystem-level copy-on-write to be done. Semi a la the union
filesystem. Basically, if a user writes to a file, the linking
is undone and the file then copied up to the modifications. In
the case of the filesystem, a new file is created "locally"
(ie in the directory over which the fs is mounted, here called
"undermounted"). Ideally, the mounting is undone (and
subsequently fails upon retries) if all files in the "overmounted" fs
have been modified (ie, exist in the undermounted fs).
These two concepts are actually complementary. The cowlink ("clink"?)
would be at the inode level, preferably simply a symlink with
addtional information specifying it as a cowlink. The filesystem
idea is less obviously useful, but I'm sure that it would be a
good thing to have in the Linux kernel's repretoire. However, the
usefulness of this system is dulled significantly by the need to
actually mount the filesystem.
As I was reading this thread, one final idea came to me. What if we
were to set up a stack (or, preferably, array-like) filesystem
structure, similar to STREAMS? Root could specify fs-modules to
be pushed (or inserted at a location, in the array paradigm) on
to the stack. Then, in turn, each fs-module would get a crack at
the filesystem request. This would easily replace the filesystem-
based copy-on-write. The fs-module is given a list of directories to
"patrol." When a request comes in for a file in the directory, it
reroutes the request based, in this case, on the copy-on-write system.
Further fs-modules could be developed for other interesting ideas.
Having them as pushable (or insertable) would also allow for easy
testing and greater control. The downside of the system would be
extra time overhead as the request gets routed through the layers.
Well, there's my pipe dream. I hope it makes sense and I wish I could
work on it. Have fun with this one. :)
-Joseph
--
Joseph==============================================jap3003@ksu.edu
"Have the appropriate amount of fun."
_Programming_Perl_, (2nd Ed.) page 34
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Mar 07 2000 - 21:00:19 EST