From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 1 06:31:26 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8885316A4CE for ; Fri, 1 Oct 2004 06:31:26 +0000 (GMT) Received: from ketralnis.dyndns.org (adsl-64-173-8-101.dsl.sntc01.pacbell.net [64.173.8.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 23B5943D2D for ; Fri, 1 Oct 2004 06:31:26 +0000 (GMT) (envelope-from ketralnis@ketralnis.dyndns.org) Received: from ketralnis.dyndns.org (localhost [127.0.0.1]) by ketralnis.dyndns.org (8.12.10/8.12.10) with ESMTP id i916V7JQ072267 for ; Thu, 30 Sep 2004 23:31:07 -0700 (PDT) (envelope-from ketralnis@ketralnis.dyndns.org) Received: from localhost (ketralnis@localhost)i916V2vq072264 for ; Thu, 30 Sep 2004 23:31:02 -0700 (PDT) (envelope-from ketralnis@ketralnis.dyndns.org) Date: Thu, 30 Sep 2004 23:31:02 -0700 (PDT) From: David King To: hackers@freebsd.org In-Reply-To: <415C9967.3090309@jonny.eng.br> Message-ID: <20040930231326.A72233@ketralnis.dyndns.org> References: <415BDFC2.1020304@fer.hr> <415C9967.3090309@jonny.eng.br> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: GEOM (ggate) compression consumer +problem X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Oct 2004 06:31:26 -0000 > 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 :)