From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Charles P. Wright" Subject: Re: built-in rotating and compressed files: rotfs and zfs Date: Thu, 22 Jan 2004 10:59:37 -0500 Sender: linux-fsdevel-owner@vger.kernel.org Message-ID: <1074787177.12904.4.camel@arcticfox.foo> References: <1074785688.400fed980f994@imp1-l.free.fr> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: linux-fsdevel@vger.kernel.org Return-path: Received: from filer.fsl.cs.sunysb.edu ([130.245.126.2]:42705 "EHLO filer.fsl.cs.sunysb.edu") by vger.kernel.org with ESMTP id S264566AbUAVP7o (ORCPT ); Thu, 22 Jan 2004 10:59:44 -0500 To: porte64@free.fr In-Reply-To: <1074785688.400fed980f994@imp1-l.free.fr> List-Id: linux-fsdevel.vger.kernel.org Look at FiST, which is available from http://www.filesystems.org. The FiST package includes gzipfs, a stackable file system that compresses and decompresses data on the fly. Charles On Thu, 2004-01-22 at 10:34, porte64@free.fr wrote: > Many applications make heavy usage of compressed files > and some need rotating files. > > Though compression methods are almost stabilized as standards, > one still does need special tools like zcat to read from them. > But many applications are not aware of zcat, zcat cannot read > byte ranges within binary files ... > > Hence a proposal: how about implementing a file compression > and a file rotation within the kernel ? > - This would make system calls like read() and write() transparent > ... so it would brought transparency to all applications > - e.g. syslog messages would be compressed on-the-fly, backup > utilities would not have to delay job queues due to compression > overcost. > - Humans would not have to bother about disk usage and machine > power when uncompressing files. > > So many advantages ! > Now, one open question: is it better to implement this at file > level (one extra attribute) or at file system level > (designing zfs and rotfs) ? > > Regards > Phil > - > To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html