From: Theodore Ts'o <tytso@mit.edu>
To: Dave Taht <dave.taht@gmail.com>
Cc: cerowrt-devel@lists.bufferbloat.net
Subject: Re: [Cerowrt-devel] Is there a particular reason cerowrt isn't using UBIFS?
Date: Sat, 30 Aug 2014 21:38:37 -0400 [thread overview]
Message-ID: <20140831013837.GB8974@thunk.org> (raw)
In-Reply-To: <CAA93jw7t88TS3t3frozK=stMFVqY7vy9NnqbptpbD4LA1Gqz2A@mail.gmail.com>
On Sat, Aug 30, 2014 at 02:57:05PM -0700, Dave Taht wrote:
> I tried ubifs in the early days. It doesn't squeeze stuff down even as good
> as jffs2, so the load of cerowrt exceeded 15mbyte. It does look to be an
> ever more reasonable answer once you have flash sizes greater than 128mbyte.
Another possible solution might be squashfs on top of ubi (instead of
mtdblock). Ubi will provide the wear levelling and bad block
remapping, which mtdblock doesn't do.
> A thing that irks me in the age of 4G flash becoming fairly common is the
> general lack of compression aside from an option to btrfs. Debian barely
> fits into 2 gb
It depends on what you have installed, of course. I have a debian
test image which gets used for ext4 testing which is 189 megabytes
uncompressed, and 57 megabytes using qcow2 compression (it gets run
using qemu/kvm)[1]. It's a basic debootstrap image plus a handful of
packages[2] plus xfstests (which is 22 megabytes uncompressed).
[1] ftp://ftp.kernel.org/pub/linux/kernel/people/tytso/kvm-xfstests/
[2] https://git.kernel.org/cgit/fs/ext2/xfstests-bld.git/tree/kvm-xfstests/test-appliance/packages
This is still much larger than 7 megabytes in the Cerowrt's root
image, granted, but it is possible to make a relatively svelte
debian-based image.
I've considered implementing MacOS X style compression (immutable
files, compression which happens in userspace, with decompression in
the kernel.) The main reason why I haven't is that for most use
cases, space hasn't really been that much of an issue, or most of the
files are already compressed (i.e., Java or Dalvik classpath files
which are already zip compressed). It wouldn't be _that_ hard to do,
but it's just not that high up on most people's priority lists.
- Ted
next prev parent reply other threads:[~2014-08-31 1:38 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-30 21:34 Theodore Ts'o
2014-08-30 21:57 ` Dave Taht
2014-08-31 1:38 ` Theodore Ts'o [this message]
2014-08-31 7:05 ` David Lang
2014-08-31 16:45 ` Theodore Ts'o
2014-08-31 17:29 ` Dave Taht
2014-08-31 19:37 ` David Lang
2014-08-31 22:03 ` Theodore Ts'o
2014-08-31 16:58 ` Dave Taht
2014-08-31 7:01 ` David Lang
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
List information: https://lists.bufferbloat.net/postorius/lists/cerowrt-devel.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140831013837.GB8974@thunk.org \
--to=tytso@mit.edu \
--cc=cerowrt-devel@lists.bufferbloat.net \
--cc=dave.taht@gmail.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