Date: Thu, 30 Sep 2004 23:31:02 -0700 (PDT) From: David King <ketralnis@ketralnis.dyndns.org> To: hackers@freebsd.org Subject: Re: GEOM (ggate) compression consumer +problem Message-ID: <20040930231326.A72233@ketralnis.dyndns.org> In-Reply-To: <415C9967.3090309@jonny.eng.br> References: <415BDFC2.1020304@fer.hr> <415C9967.3090309@jonny.eng.br>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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 :)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040930231326.A72233>