All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tom Marshall <tom@cyngn.com>
To: linux-fsdevel@vger.kernel.org
Subject: [RFC] Per-file compression
Date: Fri, 17 Apr 2015 15:20:35 -0700	[thread overview]
Message-ID: <55318733.4000503@cyngn.com> (raw)

I'd like to get some thoughts on whether having transparent per-file 
compression implemented in the kernel would be desirable.

Details:

We are running into space issues when upgrading Android devices to the 
latest version.  This issue is particularly troublesome for 64-bit 
devices that initially shipped without 64-bit support, as the multi-lib 
files nearly double the space requirements.  As it happens, many system 
files are quite compressible -- namely shared libs and apk files.  So 
implementing filesystem compression is a natural solution.

After investigating several well known compression solutions, we did not 
find any that met our goals:

* Compression should be transparent to user space.  It would be possible 
to identify subsets of the filesystem that compress well and handle 
compression in user space.  However, doing this involves repeating 
similar work in different areas of code, and can never fully utilize 
compression across the entire filesystem.

* Compression must work with existing Android filesystems.  There are 
filesystems that have native compression.  However, switching to a new 
filesystem on a released device is not really desirable.

* Compression should be implemented as transparently as possible. cloop 
is filesystem independent, but it makes the underlying device 
read-only.  This could be mitigated somewhat with overlayfs, but that 
would be a rather complex solution.

* Compression should be independent of the filesystem.  e2compr may work 
for ext2, but it seems abandoned and does not address other filesystem 
types.

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/

Note this is mostly just a prototype at the moment.  I'm fully aware 
that it has some bugs and limitations.  Pretty major ones, I'm sure.  
However, if this is something that is generally desirable, I would look 
forward to working with the VFS maintainers to make it merge worthy.

Thanks!


             reply	other threads:[~2015-04-17 22:20 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-17 22:20 Tom Marshall [this message]
2015-04-18  8:06 ` [RFC] Per-file compression Richard Weinberger
2015-04-18 23:09   ` Theodore Ts'o
2015-04-20  3:00     ` Alex Elsayed
2015-04-18 11:41 ` Richard Weinberger
2015-04-18 14:58   ` Tom Marshall
2015-04-18 15:07     ` Richard Weinberger
2015-04-18 15:48       ` Tom Marshall
2015-04-18 15:52         ` Richard Weinberger
2015-04-20 14:53       ` Tyler Hicks
2015-04-20 16:51         ` Richard Weinberger
2015-04-21 15:18           ` Theodore Ts'o
2015-04-21 15:37             ` Jeff Moyer
2015-04-21 16:54               ` Theodore Ts'o
2015-04-29 23:15             ` Tom Marshall
2015-05-01 18:09 ` Steve French
  -- strict thread matches above, loose matches on Subject: below --
2015-04-19 21:15 Tom Marshall
2015-04-21  3:29 Tom Marshall

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=55318733.4000503@cyngn.com \
    --to=tom@cyngn.com \
    --cc=linux-fsdevel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.