GEOM (ggate) compression consumer +problem

[David King]

> Instead of block compression, wouldn't it be better (and maybe easier) to use 
> file compresion, in a VFS layer (and a threaded daemon)?
>
> A real useful VFS layer would have an option to compress only rarely used 
> files.  And keep the real layer accessible, to allow dumping of compressed 
> backend files.

 	Something I've always wanted to be able to do, and have never 
found a "pretty" way, is to attach an action to reads and writes of a 
file. For instance, I have a file called foo. foo is really a front-end 
for a background file called ".foo.gz". Reading from foo gives you the 
output of "gzip -d < foo.gz" and writing to the file really directs that 
output to "gzip -c > foo.gz" This would be especially useful in 
compression scenarios like this, encryption, creating dynamic playlists, 
etc. Rarely accessed programs could be stored as source and compiled once 
in a blue moon to be run and discarded. Maybe I prefer LaTeX to HTML: a 
dynamic file could translate my LaTeX back and forth HTML on read and 
write
 	My present solution is a set of programs I call "dynfiled" 
(dynamic file daemon) that really just sits on a select() call and waits 
for reads and writes to some named pipes it creates. This has some obvious 
drawbacks in that not all programs read and write in a pipe-friendly 
manner.
 	A quick-hack-like way would be to add a link to two binary's 
inodes to the "dynamic" file's inode (one for read, one for write). This 
has the downside of limiting the command to a single binary that would 
have to check argv[0], and force it to be on the same file system 
(although a union over the top of the two FS's would be an (undesirable) 
fix), but I suppose it'd work. The speed consequences in my implementation 
are dramatic, but I don't much see a way around it, since passing 
something from disk is far faster than passing it from disk, doing and 
operation on it, then passing it up.
 	/That/ is something I'd like to see in a VFS layer :)