From: Dave Taht <dave.taht@gmail.com>
To: David Lang <david@lang.hm>
Cc: "cerowrt-devel@lists.bufferbloat.net"
<cerowrt-devel@lists.bufferbloat.net>
Subject: Re: [Cerowrt-devel] Is there a particular reason cerowrt isn't using UBIFS?
Date: Sun, 31 Aug 2014 09:58:10 -0700 [thread overview]
Message-ID: <CAA93jw4dH_X_pJoX5ZmggYV15RbYCcEBCaycN0k9pH2oHbHB+Q@mail.gmail.com> (raw)
In-Reply-To: <alpine.DEB.2.02.1408310001350.433@nftneq.ynat.uz>
On Sun, Aug 31, 2014 at 12:05 AM, David Lang <david@lang.hm> wrote:
> On Sat, 30 Aug 2014, Theodore Ts'o wrote:
>
>>> 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.
>
>
> One other place this sort of thing is likely to be useful is for Raspberry
> Pi and other small (embedded by some defintions) systems that use SD cards
> for their OS system. The I/O to the storage is so slow that the saved I/O
> time is likely to more than cover the cost of the decompression.
>
> Raspberry Pi systems have had to move to 4G cards as their base because it's
> just not possible to have the standard install do more than boot on a 2G
> card.
Beaglebone blacks updated to 4G also due to the same issue in building a useful
debian system in < 2G.
... and they increased the price 10 bucks.
The CPE market is highly price sensitive (and generally has preferred flash
soldiered to the board vs something removable)
Other things that bug me (on the x86 front), is that the onboard flash
there is usually
just large enough for the BIOS. I had kind of figured that flash sizes
there would have
increased to 8 or more MB in the general case by now, which would make
it more possible
to boot openwrt off of available on board flash (along with openbios, if needed)
Also the new systemd init system alone is bigger than available flash
on most router
platforms shipped last year; same goes for android.
(which is why openwrt went their own way with the json based procd
system:
http://wiki.openwrt.org/doc/techref/procd
)
Now, I don't know how much time we have left before there are no cost
or power reduction benefits from absurdly small flash sizes (my gut
feel is we passed those a while ago), but I do feel there are
significant benefits in an age of small caches and
weak processors, in keeping the footprint of the codebase small, and
the centralized uci based configuration system (which works well with
guis) in openwrt is unmatched by anything else - as is (now, in
barrier breaker), the ipv6, and de-bufferbloating support, and other
tight integrations with various cpe concepts.
> David Lang
--
Dave Täht
NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article
next prev parent reply other threads:[~2014-08-31 16:58 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
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 [this message]
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=CAA93jw4dH_X_pJoX5ZmggYV15RbYCcEBCaycN0k9pH2oHbHB+Q@mail.gmail.com \
--to=dave.taht@gmail.com \
--cc=cerowrt-devel@lists.bufferbloat.net \
--cc=david@lang.hm \
/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