From owner-freebsd-fs@FreeBSD.ORG Mon Oct 23 13:09:45 2006 Return-Path: X-Original-To: freebsd-fs@FreeBSD.ORG Delivered-To: freebsd-fs@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CF3A816A492 for ; Mon, 23 Oct 2006 13:09:45 +0000 (UTC) (envelope-from fjoe@neo.samodelkin.net) Received: from neo.samodelkin.net (samodelkin.net [195.62.0.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6411543D5E for ; Mon, 23 Oct 2006 13:09:45 +0000 (GMT) (envelope-from fjoe@neo.samodelkin.net) Received: by neo.samodelkin.net (Postfix, from userid 1000) id 293F3170B9; Mon, 23 Oct 2006 20:09:43 +0700 (NOVST) Date: Mon, 23 Oct 2006 20:09:43 +0700 From: Max Khon To: Oliver Fromme Message-ID: <20061023130942.GA73780@samodelkin.net> References: <451AA52F.2020408@centtech.com> <200609271744.k8RHipTS032655@lurza.secnetix.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200609271744.k8RHipTS032655@lurza.secnetix.de> User-Agent: Mutt/1.4.2i Cc: freebsd-fs@FreeBSD.ORG Subject: Re: Hi: Porting Cramfs on FreeBSD X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Oct 2006 13:09:45 -0000 Hi! On Wed, Sep 27, 2006 at 07:44:51PM +0200, Oliver Fromme wrote: > > I'm currently working on a tarfs, that will do something similar to > > this, except it allows you to use a regular tar file as the file system > > image. > > That's cool. I'm looking forward to it. > > > I don't have compression working yet, but that is on the > > roadmap. [...] large file system sizes (based on available > > memory) > > Hm. Does that mean that the whole (uncompressed) FS image > will have to fit into memory? That would be a disadvantage > compared to cramfs. Cramfs doesn't compress the whole FS > as one object (like .tar.gz), but it compresses it page-by- > page, so every page can be uncompressed independently, and > memory usage is very low, which is good for small embedded > applications. cloop (geom_uzip) works exactly like this, but on the block device level. /fjoe