linux-ext4 - Re: [RFC/PATCH 0/2] ext4: Transparent Decompression Support

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]

Date:	Fri, 26 Jul 2013 09:20:34 -0400
From:	Jörn Engel <joern@...fs.org>
To:	Vyacheslav Dubeyko <slava@...eyko.com>
Cc:	Dhaval Giani <dgiani@...illa.com>, Taras Glek <tglek@...illa.com>,
	linux-kernel@...r.kernel.org, tytso@....edu, vdjeric@...illa.com,
	glandium@...illa.com, linux-ext4@...r.kernel.org,
	linux-fsdevel@...r.kernel.org
Subject: Re: [RFC/PATCH 0/2] ext4: Transparent Decompression Support

On Fri, 26 July 2013 12:01:23 +0400, Vyacheslav Dubeyko wrote:
> 
> We are discussing not about good or bad idea. We need to elaborate a
> right solution. I think that suggested idea is not clear. Do you want to
> support compression in ext4? Or do you want to add some new compression
> feature (likewise file-oriented compression)? If we are talking about
> compression in ext4 then it needs to use e2compr patch set. Otherwise,
> if we are talking about file compression then it is not question of
> concrete filesystem. And we need to make implementation on VFS level. It
> is only architectural point of view.

I don't think the e2compr patches are strictly necessary.  They are a
good option, but not the only one.

One trick to simplify the problem is to make Dhaval's compressed files
strictly read-only.  It will require some dance to load the compressed
content, flip the switch, then uncompress data on the fly and disallow
writes.  Not the most pleasing of interfaces, but yet another option.

> Why do you try to implement likewise concept on kernel level? It looks
> like you try to move some user-space concept in kernel-space.

The kernel controls the page cache.  Once the page cache is filled
with uncompressed file content, you can do mmap, regular file io, etc.
Putting uncompression code into the kernel makes sense to me.  Whether
a solution different from e2compr makes sense is yet to be seen.

Whatever you do, it will require support from the on-disk format and
the userspace ABI.  Setting the compression bit on a file has the
clear advantage that it is an established interface and also supported
by other filesystems.  Introducing yet another interface requires a
fairly strong case to be made.  But who knows, maybe Dhaval can pull
it off.

Jörn

--
Measuring programming progress by lines of code is like measuring aircraft
building progress by weight.
-- Bill Gates
--
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