From: Dhaval Giani <dgiani@mozilla.com>
To: linux-kernel@vger.kernel.org
Cc: tytso@mit.edu, tglek@mozilla.com, vdjeric@mozilla.com,
glandium@mozilla.com, linux-ext4@vger.kernel.org,
linux-fsdevel@vger.kernel.org
Subject: [RFC/PATCH 0/2] ext4: Transparent Decompression Support
Date: Wed, 24 Jul 2013 17:03:53 -0400 [thread overview]
Message-ID: <1374699833.7083.2.camel@localhost> (raw)
Hi there!
I am posting this series early in its development phase to solicit some
feedback.
We are implementing transparent decompression with a focus on ext4. One
of the main usecases is that of Firefox on Android. Currently libxul.so
is compressed and it is loaded into memory by a custom linker on
demand. With the use of transparent decompression, we can make do
without the custom linker. More details (i.e. code) about the linker can
be found at https://github.com/glandium/faulty.lib
Patch 1 introduces the seekable zip format to the kernel. The tool to
create the szip file can be found in the git repository mentioned
earlier. Patch 2 introduces transparent decompression to ext4. This
patch is really ugly, but it gives an idea of what I am upto right now.
Now let's move on the interesting bits.
There are a few flaws with the current approach (though most are easily
fixable)
1. The decompression takes place very late. We probably want to be
decompressing soon after get the data off disk.
2. No seek support. This is for simplicity as I was experimenting with
filesystems for the first time. I have a patch that does it, but it is
too ugly to see the world. I will fix it up in time for the next set.
3. No mmap support. For a similar reason as 1. There is no reason it
cannot be done, it just has not been done correctly.
4. stat still returns the compressed size. We need to modify
compressed files to return uncompressed size.
5. Implementation is tied to the szip format. However it is quite easy
to decouple the compression scheme from the filesystem. I will probably
get to that in another 2 rounds (first goal is to get seek support
working fine, and mmap in place)
6. Introduction of an additional file_operation to decompress the
buffer. This will be *removed* in the next posting once I have seek
support implemented properly.
7. The compressed file is read only. In order to write to the file, it
shall have to be replaced.
8. The kernel learns that the file is compressed with the use of the
chattr tool. For now I am abusing the +c flag. Please let me know if
that should not be used.
In order to try this patch out, please create an szip file using the
szip tool. Then, read the file. Just ensure that the buffer you provide
to the kernel is big enough to fit the uncompressed file (and that you
read the whole file in one go.)
Thanks!
Dhaval
--
Dhaval Giani (2):
szip: Add seekable zip format
Add rudimentary transparent decompression support to ext4
fs/ext4/file.c | 66 ++++++++++++++++
fs/read_write.c | 3 +
include/linux/fs.h | 1 +
include/linux/szip.h | 32 ++++++++
lib/Kconfig | 8 ++
lib/Makefile | 1 +
lib/szip.c | 217 +++++++++++++++++++++++++++++++++++++++++++++++++++
7 files changed, 328 insertions(+)
create mode 100644 include/linux/szip.h
create mode 100644 lib/szip.c
--
1.8.1.4
next reply other threads:[~2013-07-24 21:03 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-24 21:03 Dhaval Giani [this message]
2013-07-24 23:36 ` [RFC/PATCH 0/2] ext4: Transparent Decompression Support Jörn Engel
2013-07-25 15:16 ` Dhaval Giani
2013-07-25 15:29 ` Phillip Lougher
2013-07-25 16:42 ` Taras Glek
2013-07-25 17:53 ` Jörn Engel
2013-07-25 19:27 ` Dhaval Giani
2013-07-25 18:15 ` Vyacheslav Dubeyko
2013-07-25 18:35 ` Dhaval Giani
2013-07-26 8:01 ` Vyacheslav Dubeyko
2013-07-26 13:20 ` Jörn Engel
2013-07-29 23:15 ` Mike Hommey
2013-08-04 0:33 ` Theodore Ts'o
2013-08-04 2:21 ` Jörn Engel
2013-08-04 23:48 ` Dave Chinner
2013-08-07 9:21 ` Andreas Dilger
2013-08-07 15:52 ` Jörn Engel
[not found] ` <51F16B9A.5020006@mozilla.com>
2013-07-26 7:47 ` Vyacheslav Dubeyko
2013-07-25 18:05 ` Jörn Engel
2013-07-25 20:09 ` Zach Brown
2013-07-25 18:46 ` Jörn Engel
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=1374699833.7083.2.camel@localhost \
--to=dgiani@mozilla.com \
--cc=glandium@mozilla.com \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tglek@mozilla.com \
--cc=tytso@mit.edu \
--cc=vdjeric@mozilla.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).