From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from imap.thunk.org (imap.thunk.org [IPv6:2600:3c02::f03c:91ff:fe96:be03]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client CN "imap.thunk.org", Issuer "CAcert Class 3 Root" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 4FE5E21F359 for ; Sun, 31 Aug 2014 15:03:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=thunk.org; s=ef5046eb; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=aN7BEyl8c6NRjpfxeLdONUdIQknjFVx2h+n0pj88D/U=; b=f8jeROfmxmnZDCKKpESGExVL5tri04esceb5lq/iDInpjFBEeYajj1/gZZgN5ctq6AwwZRM58sycEIhJ312KJeqxw4/blrIYE0V9cdxrbZg5TzIP1gwNhsRFFBKkgN+PAMRb8OdtRTfQiXoTLEk+eWFjHX0k2BohdlcZ/6LjeSE=; Received: from root (helo=closure.thunk.org) by imap.thunk.org with local-esmtp (Exim 4.80) (envelope-from ) id 1XODDH-0005Vq-VJ; Sun, 31 Aug 2014 22:03:08 +0000 Received: by closure.thunk.org (Postfix, from userid 15806) id 45D8A58120D; Sun, 31 Aug 2014 18:03:07 -0400 (EDT) Date: Sun, 31 Aug 2014 18:03:07 -0400 From: Theodore Ts'o To: David Lang Message-ID: <20140831220307.GI8974@thunk.org> References: <20140830213451.GA30271@thunk.org> <20140831013837.GB8974@thunk.org> <20140831164531.GE8974@thunk.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: tytso@thunk.org X-SA-Exim-Scanned: No (on imap.thunk.org); SAEximRunCond expanded to false 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 22:03:10 -0000 On Sun, Aug 31, 2014 at 12:37:07PM -0700, David Lang wrote: > As a datapoint in this discussin, take a look at the openwrt thread > [OpenWrt-Devel] Toolchain issue: Significant decrease in performance of > binaries produced by Barrier Breaker relative to Attitude Adjustment > > Apparently with BB they changed the gcc options on mips to produce 16 bit > code because it results in smaller binaries, but this cripples performance > in some cases > > It doesn't answer your funding issue, but it shows another case of people > being very sensitive to storage size. Right, but *wrt is a bit of a special case, since what we're trying to do here is shoehorn a different software load unto pre-existing hardware where someone else has already cost-optimized the BOM so that it only has, say, 8MB of flash instead of 16MB of flash. But if company is designing a new product from scratch, the delta to the BOM cost of using 16MB of flash versus 8MB of flash (unless the company is making gazillions of units) is probably not going to justify sponsoring an engineer to do open source work on a new file system feature. So I'm sure there are cases where people are sensitive to storage size --- including for example, handset companies who want to be able to install a newer version of Android on an older handset which doesn't have enough flash for Kit Kat, or some such.... (and I hear the peanut gallery burst into laughter at this point --- what? handset vendors caring about software updates? They *want* people to buy a new phone since that's the only way they get money out of the deal. And if they can use the excuse of, "so sorry, the handset doesn't have enough flash storage space to upgrade to Kit Kat", so much the better. :-) :-/ - Ted