On 2015-04-18 17:07:16, Richard Weinberger wrote: > Hi! > > Am 18.04.2015 um 16:58 schrieb Tom Marshall: > > On Sat, Apr 18, 2015 at 01:41:09PM +0200, Richard Weinberger wrote: > >> On Sat, Apr 18, 2015 at 12:20 AM, Tom Marshall <tom@xxxxxxxxx> wrote: > >>> So, I wrote a thing called 'zfile' that hooks into the VFS layer and > >>> intercepts file_operations to do file (de)compression on the fly. When a > >>> file is opened, it reads and decompresses the data into memory. The file > >>> may be read, written, and mmaped in the usual way. If the contents are > >>> changed, the data is compressed and written back. A working patch for an > >>> older kernel version may be found at: > >>> http://review.cyanogenmod.org/#/c/95220/ > >> > >> So, I've extracted the patch from that website and gave a quick review. > >> > >> I'm pretty sure VFS folks will hate the VFS layering you do. > > > > This, I'm afraid, is the biggest obstacle to such a solution. I know that > > OverlayFS has been merged, so filesystem stacking is acceptable. Perhaps > > there would be a way to design a filesystem that stacks compression? > > That's why I said think of adding compression support to ecryptfs. I think adding compression support to eCryptfs is the wrong approach. The "X is already a stacked filesystem so look into adding compression support to it" logic also works when X=overlayfs. I doubt that Miklos would be willing to accept such a feature. :) A stacked filesystem that implements compression should be fairly simple. If it is not simple, it is too complicated to try to wedge into an unrelated stacked filesystem. While it may be the quickest route to your end goal, it will overly complicate eCryptfs. eCryptfs already has plenty of complexity around the file offset since metadata may be stored in the first 8192 bytes of the lower file, which offsets the entire file, and the end of the file has to be padded. Mixing in compression would make things much worse. Also, eCryptfs has lots of cruft that is definitely not needed for compression. Please consider a small, standalone stacked fs to handle compression. Tyler > > >> Beside of that you decompress the *whole* file into memory at open() time. > >> This will explode as soon you deal with bigger files. > > > > I was thinking that a header with compressed offsets might be an option. Or > > in the case of lz4 it's not terribly inefficient to scan the blocks. > > > >> Also you seem to trust the user.compression.realsize xattr provided by > >> userspace. That looks exploitable. > > > > This is only used to provide a fast stat(). It could be put into a header > > or even removed entirely in favor of scanning the blocks. > > > >> Back to my original question, why not FUSE? > > > > Mostly because I'm not very familiar with FUSE. But I suppose it could be > > an option. I have some immediate concerns though: > > > > * How would it affect performance? FUSE passes all operations through user > > space, correct? > > Yeah, but you'll have to do benchmarks to find out the real trade off. > I'd give it a tray. Your targets are smartphones not HPC clusters. > > > * How big might a reasonably complete implementation be for ARM? The > > implementation would need to be stored in the initrd. > > I bet you can do it in less than 1000 lines of C... > > >> Or add compression support to ecryptfs... > > > > Several filesystems have native compression support. But this would violate > > the goal of not switching filesystems. > > ...your goals. Be flexible. ;) > BTW: ecryptfs is an overlay filesystem. > > Thanks, > //richard > -- > To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html
Attachment:
signature.asc
Description: Digital signature
