linux-kernel - Re: [RFC] Btrfs mainline plans

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 7 Oct 2008 18:27:40 +0300
From:	Adrian Bunk <bunk@...nel.org>
To:	Chris Mason <chris.mason@...cle.com>
Cc:	"Serge E. Hallyn" <serue@...ibm.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-fsdevel <linux-fsdevel@...r.kernel.org>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	linux-ext4@...r.kernel.org, Theodore Tso <tytso@....edu>
Subject: Re: [RFC] Btrfs mainline plans

On Mon, Oct 06, 2008 at 09:40:03AM -0400, Chris Mason wrote:
> On Sun, 2008-10-05 at 18:09 +0300, Adrian Bunk wrote:
> > On Sun, Oct 05, 2008 at 09:11:13AM -0500, Serge E. Hallyn wrote:
> > > Quoting Adrian Bunk (bunk@...nel.org):
> > >
> 
> [ when to merge btrfs ]
> 
> > > > Let's try to learn from the past:
> > > > 
> > > > 6 days from today ext4 (another new local filesystem for Linux) 
> > > > celebrates the second birthday of it's inclusion into Linus' tree
> > > > as a similar special-case.
> > > > 
> > > > You claim "an early merge will accelerate its development and will 
> > > > broaden its developer base" for Btrfs.
> > > > 
> > > > Read the timeline Ted outlined back in June 2006 for ext4 [1].
> > > > When comparing with what happened in reality it kinda disproves
> > > > your "acceleration" point.
> > > 
> 
> The btrfs timelines have always been aggressive, and as btrfs gets
> closer to feature complete, the testing matrix grows dramatically.  I
> can't promise my crazy timelines won't slip, but I've been hacking away
> in the basement for almost 18 months now and it's time for me to get off
> the pot and make it stable.
> 
> Ext4 has always had to deal with the ghost of ext3.  Both from a
> compatibility point of view and everyone's expectations of stability.  I
> believe that most of us underestimated how difficult it would be to move
> ext4 forward.
> 
> Btrfs is different for lots of reasons, and being in mainline will
> definitely increase the pressure on the btrfs developers to finish, and
> the resources available for us to finish with.

Your last sentence does not make sense:

According to your timeline btrfs 1.0 will be released in Q408 [1] - and
the merge window for 2.6.29 will be in Q109.

>...
> > For people wanting to try WIP code you don't need it in mainline.
> > 
> > Stable kernels will anyway usually contain months old code of the
> > WIP filesystem that is not usable for testing, so for any meaningful
> > testing you will still have to follow the btrfs tree and not mainline.
> 
> For ext4 at least, the mainline code is very usable.  I hope to have
> btrfs in shape for that by the 2.6.29 merge cycle.

One risk you should be aware of is that when btrfs is in 2.6.29 part of 
the Linux press might pick it up and stress test and benchmark this new 
filesystem.

JFS still suffers from from not being that good when it was
initially merged.

> -chris

cu
Adrian

[1] http://btrfs.wiki.kernel.org/index.php/Development_timeline

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

--
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/