Message-ID: <20090810132934.GC20471@mit.edu>
Date:	Mon, 10 Aug 2009 09:29:34 -0400
From:	Theodore Tso <tytso@....edu>
To:	Daniel Phillips <phillips@...nq.net>
Cc:	Ingo Molnar <mingo@...e.hu>, Jeff Garzik <jgarzik@...ox.com>,
	debian developer <debiandev@...il.com>,
	OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>, tux3@...3.org,
	LKML <linux-kernel@...r.kernel.org>, corbet@....net
Subject: Re: [Tux3] Current Activities?

On Sat, Aug 08, 2009 at 04:47:21PM -0700, Daniel Phillips wrote:
> I will very briefly address Ted's question, which amounts to: "why
> do we want Tux3?"  I think Tux3 fills an empty niche in our filesystem
> ecology where a simple, clean and modern general purpose filesystem
> should exist and there is none.  

You'll need to define "simple", "clean", and "modern" here; but this
isn't something that makes a lot of sense to an end-user.

> In concrete terms, Tux3 implements a
> single-pointer-per-extent model that Btrfs and ZFS do not.  This allows
> a very simple *physical* design, with much complexity pushed to the
> *logical* level where things generally behave better.  

This isn't very compelling, either....

> A simple physical
> design offers many benefits, including making it easier to take a run at
> that holiest of holy grails, online check and repair.

Note that a simple physical design does not necessarily enable online
check/repair.  In fact, without back pointers (which add complexity),
doing online checking can be completely impractical for large
filesystems.  There's been quite a lot of thinking on this subject;
see Val's "Repair-driven Filesystem Design" paper.

> In even more concrete terms, Tux3 already demonstrates a tiny memory
> footprint, unlike Btrfs or ZFS.  Its CPU footprint is also tiny.  As
> such, Tux3 could easily run on a cellphone or smaller device, while
> offering a full range of "big filesystem" capabilities.  (Note that
> Zumastor already proves we know how to do replication properly:
> http://zumastor.org/.)

Well, btrfs currently weighs in at 302k of compiled object code.
While that's certainly not small (ext4+jbd2 weighs in at 256k;
ext3+jbd weighs in at 124k; ext2 at 42k), 300k isn't going to break
the bank on most cell phones that would be running Linux these days.
And on a cell phone, it might very well be that some flash-based
filesystem such as JFFS2 or UBIFS would be a better choice in any
case.

If the goal is to find corporate sponsorship for Tux3, I'd strongly
encourage you to think harder about a compelling story for why Tux3 is
so cool that companies should spend money supporting it.  Let me
gently suggest to you that "it'll have fewer features than btrfs, but
it will use less memory" is not a particularly compelling story to a
company's technical and management leadership who is figure out
spending priorities for next year's budget.  Particularly if the cell
phone is going to have megabytes of memory to run Java on it anyway;
and even if it's not running Java, have you seen how much space
graphical libraries take up these days?  :-)

Again, I'm not saying this to discourage technical people from working
on Tux3.  But just because you're passionate about a technology,
doesn't mean that it automatically translate to there being a business
case to convince companies to invest in that technology.

Best regards,

              	   	    	       	   	- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists