Re: silent semantic changes with reiser4

[Timothy Miller]

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/