linux-ext4 - Re: ext5

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20100211043029.GE739@thunk.org>
Date:	Wed, 10 Feb 2010 23:30:29 -0500
From:	tytso@....edu
To:	Manish Katiyar <mkatiyar@...il.com>
Cc:	"Anonymous Remailer (austria)" <mixmaster@...ailer.privacy.at>,
	linux-ext4@...r.kernel.org
Subject: Re: ext5

On Thu, Feb 11, 2010 at 09:08:36AM +0530, Manish Katiyar wrote:
> 
> Is this design somewhere on net so that we can read/lookup it up ?

Not yet, but the basic idea is to do the compression in userspace,
using libz with regular resync points every 64k or 128k of
uncompressed data.  An array, indexed by each fixed-block of
uncompressed data, is located at the beginning of the file indicating
where each compressed block begins.  The file is stored on-disk
written by the installer in a compressed format, and then the
installer flips an attribute bit which marks the file as containing
compressed data, and which also makes the file immutable.  (Any
attempt to open the file read/write will result in an error.)

The advantage of this scheme is that it minimizes in-kernel
complexity, since the kernel doesn't have to deal with compressing
data, and it means we can use a simpler format which is more efficient
from a compression standpoint since we don't have to deal with random
access writes.

Another advantage of this scheme is that it's relatively easy to do
the bulk of the work in a file system-independent layer.  Some minor
work would be needed to interface the attribute bit and the mmap
reading function into each client filesystem, but it should be
possible to isolate 95% of the work into a filesystem independent
layer, and then make this something which multiple file systems could
take advantage of --- not just ext3 and ext4, but also xfs, btrfs,
etc.

						- Ted

--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html