From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oa0-x22d.google.com (mail-oa0-x22d.google.com [IPv6:2607:f8b0:4003:c02::22d]) (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 896B721F3E9 for ; Sun, 31 Aug 2014 09:58:11 -0700 (PDT) Received: by mail-oa0-f45.google.com with SMTP id n16so3177332oag.32 for ; Sun, 31 Aug 2014 09:58:10 -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=NMLb+lI9uMDdmKfGcNtjLge1n6QeCtC0unW7KSRQJeU=; b=Vy9N8QENPYy0pwDvkMo+FlwsZi8m27bXt241BiU3BhSohe5LQctRkQ7hwFNDcHhfRp 2qnOQ4RtJih2fgSqxVmKmfdhK1n7ysqpxM5w54bFjsWhuFy3MMwUJqA4w1tJV01BpGkq MKKA9v6LKygq1bZ2mQLnDxcLNmWBhLk7cpvjRntXfhGj5ZwqLdcCo8GkofCU+hN7lHuC X775Zpvgf1oWEnVV0P28SXFbG0v1xu8ryhHS4N0TmZblYGapmJJMDHnhkfNjwL6jmA+M mMEdDT0sU6fcqypXQl6XkoY63uLkyPiCGkzcn9QJ6NTIS3cZgd8rlO2J7ljjLw5YoVgZ V62g== MIME-Version: 1.0 X-Received: by 10.60.65.35 with SMTP id u3mr22346628oes.35.1409504290679; Sun, 31 Aug 2014 09:58:10 -0700 (PDT) Received: by 10.202.227.76 with HTTP; Sun, 31 Aug 2014 09:58:10 -0700 (PDT) In-Reply-To: References: <20140830213451.GA30271@thunk.org> <20140831013837.GB8974@thunk.org> Date: Sun, 31 Aug 2014 09:58:10 -0700 Message-ID: From: Dave Taht To: David Lang 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 16:58:11 -0000 On Sun, Aug 31, 2014 at 12:05 AM, David Lang 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 t= he >>> general lack of compression aside from an option to btrfs. Debian barel= y >>> 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/t= est-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 Raspberr= y > Pi and other small (embedded by some defintions) systems that use SD card= s > 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 i= t'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 us= eful 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 ne= eded) 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 --=20 Dave T=C3=A4ht NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_= indecent.article