built-in rotating and compressed files: rotfs and zfs

built-in rotating and compressed files: rotfs and zfs

[porte64]

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

Re: built-in rotating and compressed files: rotfs and zfs

[Charles P. Wright]

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