Re: ext5

[Ron Johnson <ron.l.johnson@cox.net>]

On 2010-02-11 00:44, tytso@mit.edu wrote:
> On Wed, Feb 10, 2010 at 11:18:21PM -0600, Ron Johnson wrote:
>>> We currently don't have any plans for an "ext5".  There might be some
>>> new features that might gradually trickle into ext4; for example
>>> there's someone who I may be mentoring who is interested in working on
>>> an idea I've had to add read-only compression to ext4.  (Actually, the
>>> design I've sketched out makes 90% of the work be file system
>>> independent, so it's something that could be retrofitted into other
>>> filesystems: xfs, btrfs, etc.)
>> I guess that means every file on the fs?
> 
> No, I mean per-file compression, but a compressed file is immutable.
> This is basically what Mac OS X has recently added, and while I
> haven't looked at their implementation, Apple being one of those
> closed source companies and all, I wouldn't be surprised if they did
> things the same way.
> 
>> Windows-like per-file compression would be darned useful in certain
>> circumstances.  Big mbox files, for example.
> 
> The problem with mbox files is that some mail readers try to smart
> about how they modify them to avoid needing to rewrite the whole mbox
> file; mutt will seak to the middle of the file, write to the end of
> the file, and then trim off any excess space by using the truncate
> system call.  This is *hard* to support if the mbox file is
> compressed; you can do it using a stacker-style compression technique,
> but it's not as efficient, and it has a lot of complexity in the
> kernel.

I guess that's how Windows does it?

> The idea with read-only compressed files is that they are useful for
> large executables or large static files, where compressing them means
> that it takes less time to read them off of an HDD.

Sure.  Anything is better than nothing!

-- 
"Hell hath no fury like the vast robot armies of a woman scorned."
Walt