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!
next 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.