Development issues regarding the cerowrt test router project
 help / color / mirror / Atom feed
From: Theodore Ts'o <tytso@mit.edu>
To: David Lang <david@lang.hm>
Cc: cerowrt-devel@lists.bufferbloat.net
Subject: Re: [Cerowrt-devel] Is there a particular reason cerowrt isn't using UBIFS?
Date: Sun, 31 Aug 2014 12:45:31 -0400	[thread overview]
Message-ID: <20140831164531.GE8974@thunk.org> (raw)
In-Reply-To: <alpine.DEB.2.02.1408310001350.433@nftneq.ynat.uz>

On Sun, Aug 31, 2014 at 12:05:52AM -0700, David Lang wrote:
> 
> 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.

Yeah, that's the main argument I've heard for wanting to do
decompression; it's to speed up I/O when using HDD's and cheap flash
that has a minimal number of flash channels.

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

2G SD cards --  $42.95 for a 10-pack
4G SD cards --  $53.95 for a 10-pack

I have a design for adding compression, but except as a hobby effort,
I've had a lot of trouble finding a company who would be willing to
support an engineer to actually do the effort.  :-( 

Unless the company is making a truly vast number of devices, and are
very sensitive to the BOM cost, it might not make sense from an
engineering / business plan point of view.

So it will probably be something I do "for fun", when I can find the
time.... and there are a lot of other projects where companies are
willing to sponsor engineers to add new features, such as encryption,
reflink support, data checksums, etc., where if I can help them land
those features, it's unfortunately going to be higher priority than my
personally working on compression support for ext4.

But if someone is interested in working on it, they should talk to me;
I'd be happy to work with someone interested in working on the
project.

							- Ted

  reply	other threads:[~2014-08-31 16:45 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 [this message]
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=20140831164531.GE8974@thunk.org \
    --to=tytso@mit.edu \
    --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