From: Theodore Ts'o <tytso@mit.edu>
To: Richard Weinberger <richard.weinberger@gmail.com>
Cc: Tom Marshall <tom@cyngn.com>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>
Subject: Re: [RFC] Per-file compression
Date: Sat, 18 Apr 2015 19:09:12 -0400 [thread overview]
Message-ID: <20150418230912.GC25265@thunk.org> (raw)
In-Reply-To: <CAFLxGvztu7uDDyg00VdUkuZke3NTF1NHA78cbxz2vd3+8q33aA@mail.gmail.com>
On Sat, Apr 18, 2015 at 10:06:14AM +0200, Richard Weinberger wrote:
> On Sat, Apr 18, 2015 at 12:20 AM, Tom Marshall <tom@cyngn.com> wrote:
> > 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.
Tom, have you verified whether or not this approach actually is
sufficient to address the problem you are trying to solve?
Specifically, (a) can you get enough space compression that it will
make things fit? Given that apk files are already compressed using
zip, I'm a bit surprised you would get enough of a compression savings
that it's going to allow to make things fit. And secondly (b) after
you decompress the shared libraries, is there enough memory that the
resulting system functions well. Often times these older Android
devices don't have a huge amount of memory, and so either with or
without the overhead of needing to decompress the entire file (which
can be solved with chunking, although this tends to reduce the
compression efficiency), is the system going to function well using
64-bit binaries that take up a lot more room than the older 32-bit
binaries?
> > 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.
Do you really need to be able to rewrite the files? Life gets much
easier if you can assume that the compressed files are read-only;
especially once you start trying to use chunking, it *definitely*
becomes easier if you don't need to support modifying the compressed
files. And in the case of the system partition, this might be a safe
assumption,yes?
- Ted
next prev parent reply other threads:[~2015-04-18 23:09 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-17 22:20 [RFC] Per-file compression Tom Marshall
2015-04-18 8:06 ` Richard Weinberger
2015-04-18 23:09 ` Theodore Ts'o [this message]
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=20150418230912.GC25265@thunk.org \
--to=tytso@mit.edu \
--cc=linux-fsdevel@vger.kernel.org \
--cc=richard.weinberger@gmail.com \
--cc=tom@cyngn.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).