Message-ID: <Pine.LNX.4.63.0611020219290.14187@alpha.polcom.net>
Date:	Thu, 2 Nov 2006 02:44:28 +0100 (CET)
From:	Grzegorz Kulewski <kangur@...com.net>
To:	Andreas Dilger <adilger@...sterfs.com>
Cc:	Dave Kleikamp <shaggy@...tin.ibm.com>,
	ext4 development <linux-ext4@...r.kernel.org>
Subject: Re: ext4 roadmap

On Thu, 2 Nov 2006, Andreas Dilger wrote:
> On Nov 02, 2006  00:52 +0100, Grzegorz Kulewski wrote:
>> Is there any chance to get compression and/or encryption in ext4?
>
> Note that all of the features mentioned in the list at least have some
> kind of prototype already or people working on it.  It isn't really a
> "feature request list".  I'm not sure how many people are interested
> in compression/encryption, but if they are they should come forward
> with a patch.

I understand that. Unfortunatelly I don't have enough time to write 
something like that and my knowledge about ext3/4 in the kernel is pretty 
limited too.

***This is only an idea if somebody with more code knowledge has time and 
thinks that this is worth implementing. This is simply something that I, 
a user (maybe a little more advanced one, but still user) of ext3, thinks 
would be usefull.***

Also (as to the compression) I think Linux's VFS and page cache and so on 
operates rather on data amounts of constant length and isn't too well 
suited for making them smaller (or larger) somewhere in the middle 
between userspace and the disk. But maybe I am completly wrong about it. 
But if I am not wrong extending core Linux components to allow easy 
generic compression (or other manipulation that changes size) should be 
probably done in cooperation with something that works pretty close with 
core kernel components (like ext3/4 in my opinion does). This could 
possibly allow to avoid having 10 different implementation for each 
filesystem in the future. Compression and especially encryption should not 
be (in my opinion) too much fs dependent (fs should not care too much 
about data only about metadata) and should have only minimal per-fs 
support (additional metadata to allow discovering that file was 
compressed and to allow seeks for example). But again, maybe I am 
completly wrong.

As to the encryption and per-dir quota they should be probably easier (I 
hope). Maybe even I can try to hack something like that if somebody could 
tell me how to do it in a way to not break too much in the process). But 
they would probably require some ext3 on-disk filesystem layout changes 
(and e2progs changes too) so maybe ext4-development time is good to 
introduce them?


> Note that there was previously a compression patch for ext2, maybe that
> could be moved forward for ext4?

I know about ext2 patch (I even think there was more than one) and I even 
used it in those old days when linux distro could be made to fit on 250MB 
disk without too much problems. I think I ever know (one of?) the author 
of it personally. Unfortunatelly IIRC this was rather some not very pretty 
and efficient hack. It should be probably reimplemented from scratch 
rather than ported. I think too much (journaling, ...) changed since then 
in ext3/4. But again, maybe I am completly wrong and those old bits of 
code could be made to work on newer kernels somehow.


Thanks,

Grzegorz Kulewski

-
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