From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ob0-x234.google.com (mail-ob0-x234.google.com [IPv6:2607:f8b0:4003:c01::234]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 72F8E21F3F7 for ; Sun, 31 Aug 2014 10:29:10 -0700 (PDT) Received: by mail-ob0-f180.google.com with SMTP id m8so3242615obr.11 for ; Sun, 31 Aug 2014 10:29:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=v7ERUHM57JlFrFd9tjM4ekIIX3UnDHDjXdu0jb139kc=; b=ssBaTacuPvgSvFNn8YBMRCBtV7mNDPuuSxIfOUFmDtPvf4QDe8LDke2VpqNJKoUtoN 5NwQ6JnE1LL2PzR+mY7Uyi7Ipz1fAXIzMaT+yAUqkpJMTGrcDwUGhhqaPn2I1VQ8m64p 2STSylW6t5ONBvKIkdwIiq3pbDcbYsPQiRoIdOqsWAUq/5F4h4Cp71FQQhqQemKZGZ/C vnWPgj59u1JwtII/cc11QYIpzlet3pP45d7hd6+GxJc9PIhyUGzu6W7Edg5A8dcv25v7 Zepqdv8BQhVlmQ9SNwPc7yZaiKkhveXAnRcAUmqpI5AU+7DOZnHptchudg61rDDcP49x ceZg== MIME-Version: 1.0 X-Received: by 10.182.71.104 with SMTP id t8mr1763593obu.71.1409506149572; Sun, 31 Aug 2014 10:29:09 -0700 (PDT) Received: by 10.202.227.76 with HTTP; Sun, 31 Aug 2014 10:29:09 -0700 (PDT) In-Reply-To: <20140831164531.GE8974@thunk.org> References: <20140830213451.GA30271@thunk.org> <20140831013837.GB8974@thunk.org> <20140831164531.GE8974@thunk.org> Date: Sun, 31 Aug 2014 10:29:09 -0700 Message-ID: From: Dave Taht To: "Theodore Ts'o" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "cerowrt-devel@lists.bufferbloat.net" Subject: Re: [Cerowrt-devel] Is there a particular reason cerowrt isn't using UBIFS? X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Aug 2014 17:29:10 -0000 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 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 Raspber= ry >> Pi and other small (embedded by some defintions) systems that use SD car= ds >> 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 standb= ys 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 t= hat they can't go it alone. I am loving the hipnet, homenet and homewrt's efforts to further their goal= s, 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-h= ipnet/ http://www.homewrt.org/doku.php These groups have realized that for certain key new features, once identifi= ed, they can't get them from the ODM, but have to go direct to the authors of t= he 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 --=20 Dave T=C3=A4ht NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_= indecent.article