On 2010-02-11 00:44, tytso@xxxxxxx 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
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
