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
| ||
|
Message-ID: <20130726132034.GB21977@logfs.org> 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
Powered by blists - more mailing lists