[Cerowrt-devel] Is there a particular reason cerowrt isn't using UBIFS?

[Dave Taht]

Ted:

Certainly making the big cpe makers and ISPs better able to meet their
market requirements in the open source age is high on my list of
things to fix.

In the bad old days, a cpe maker would put out a big RFP with their
requirements, some big ODM or ODMs would bid on it, and after 5 years
the next product would come out, 2+ years late, there would be
acrimony and finger pointing on all sides, and the product would not
be as good as it could be.

In the present day, it really pays for the cpe maker (or ISP) to "feed
the penguins" - to identify key technologies *and their primary
authors* during their RFP process, and to try to put a floor under
them directly, to get the code more "out there" in an 18 month
timescale... and thus thoroughly tested before it has to be integrated
and then burned into flash by the ODM.

I think this approach chops of *years* of development time off of
shipping new stuff into embedded systems, and results in a much higher
quality product overall as the new features have the elegance, and
robustness that only an author with time, taste, and resources, can
produce.


On Sun, Aug 31, 2014 at 9:45 AM, Theodore Ts'o <tytso at mit.edu> wrote:
> 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.

Faster boot times are good.

I also tend to think "using less flash" out of your total might extend the
service life. I do not have a good awareness of what filesystem(s)
people are planning to ship in the next generation of embedded systems,
certainly I see a lot of ext4, I've seen some try btrfs, and the old standbys
of squashfs and jffs2 are still good choices when you are below 32MB flaash.

Better tailoring a fs (as ubi did) for better speed, higher
reliability and easy updates in the field strikes me as a very good
idea.

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

It really is astounding isn't it!

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

It's a small matter of finding a company or companies with sufficient
vision, moving
potentially millions of units, that want to save 20 cents each, realizing that
they can't go it alone.

I am loving the hipnet, homenet and homewrt's efforts to further their goals,
which are much wider than "saving money" - but in making new technologies
more available on cpe.

http://www.cablelabs.com/the-future-of-home-networking-putting-the-hip-in-hipnet/

http://www.homewrt.org/doku.php

These groups have realized that for certain key new features, once identified,
they can't get them from the ODM, but have to go direct to the authors of the
technologies in our new age modern open source world in order to get them
done enough - and "out there" enough and tested enough - for the ODM
to integrate
and ship, and put floors under various things needed.

(I was delighted comcast stepped up to get dnssec into dnsmasq,
in particular. So many people were whining about lack of dnssec adoption...

and there has been much work on routing protocols as an outgrowth of
all that, also... and so much behind the scenes integration and automation
work in that quest for extra nines of reliability. )


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

I will put possible work on ext4 compression and on ubifs on the
possible roadmap for the next phase of the cerowrt effort.

>                                                         - Ted



-- 
Dave Täht

NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article