Re: silent semantic changes with reiser4
From: Timothy Miller
Date: Thu Sep 09 2004 - 21:12:30 EST
Jamie Lokier wrote:
[snip
When a simple "cd" into .tar.gz or .iso is implemented properly, it
will have _no_ performance penalty after you have first looked in the
file, so long as it remains in the on-disk cache. And, the filesystem
will manage that cache intelligently.
Imagine: for looking at source files and such, you probably won't
bother untarring in future, and you won't bother keeping untarred
source trees in your home directory for easy access to things you look
at often. Why waste the space? You could install whole applications
as a .tar and run them from within it, with no performance penalty.
Similarly, the filesystem will be able to archive directories
automatically that haven't been touched in a long time, with no
visible change except increased storage space. "grep" will be a bit
slower, but you'll have a useful search tool by then (using coherent
indexes) which will be more useful than grep, and much faster.
[Again, pardon me for being 5000 messages behind.]
Anyhow, I recall reading an article about 'unified name spaces', and I'm
not referring to what's on namesys.com. It mentioned how putting device
nodes into the file system is a very powerful innovation of UNIX.
Having files and devices in the same name space simplifies tools and
makes the environment much more powerful, because you can connect data
sources and targets together more arbitarily.
If I recall correctly, the article mentioned something about Plan9
taking things to a greater extreme than UNIX.
Going along with what you said, Jamie, if "containers" like tar files
could be accessed like directories without being first extracted, it
would increase the power and flexibility of the whole system. Windows
XP does something like this with the way it presents ZIP files as
directories, and although I'm sure the Windows way isn't nearly as
efficient and universal as how Linux would do it, I find the feature to
be INCREDIBLY useful.
Of course, we don't necessarily want codecs for every archive format
ever invented to be embedded in the kernel. Instead, we need to do
something like how you can mount an ISO on a loopback device, only more
transparently and more flexibly, and with the less performance-critical
codecs being implemented as daemons in userspace.
Also, there would be limitations. For instance, many such
pseudo-directories would be read-only, and some would be writable only
when on some file systems (like writing to a compressed archive might be
much easier to implement on Reiser4 than something else, or perhaps the
ext3 version would have to do a lot more copying, while the Reiser
version could take advantage of Reiser-specific features like inserting
in the middle of a file).
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/