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]

Message-Id: <200810081433.32766.phillips@phunq.net>
Date:	Wed, 8 Oct 2008 14:33:32 -0700
From:	Daniel Phillips <phillips@...nq.net>
To:	Adrian Bunk <bunk@...nel.org>
Cc:	"Serge E. Hallyn" <serue@...ibm.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Chris Mason <chris.mason@...cle.com>,
	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 Sunday 05 October 2008 08:09, Adrian Bunk wrote:
> "accelerate its development and will broaden its developer base" is not 
> about users/testers but about people doing code development.
> 
> For people wanting to try WIP code you don't need it in mainline.

But it saves time for the user, who does not have to run around chasing
links, carefully checking for a kernel match, downloading, patching,
building and installing a single purpose kernel, and bringing it up on
a machine that would probably have only required one click on the new
filesystem option otherwise.  The considerable time thus saved can be
invested profitably in running test cases and filing bug reports.

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

True, but the trick here is getting started.  It is much easier to
justify the effort of going out and getting the latest patch if one
knows from experience that it basically already works.

> This is not meant as a statement on the quality of ext4 or btrfs, or any 
> comparison of the development times of ext4 and btrfs, but for ext4 the 
> advantages Andrew thinks would happen with an early btrfs merge do not 
> seem to have happened.

Are you sure about that?  I see 33 messages on linux-ext4 yesterday,
from a broad range of contributors.  Versus eight from a much narrower
range of contributors, Oct 4 a year ago.

There is little question that an early merge helps both developers and
users employ their time more efficiently, once a project is past the
point where we wonder about its value and/or viability.  In my opinion,
Btrfs clearly has both.  Particularly because we need a way to stem the
loss of mindshare to ZFS in the storage space, which is significant at
the moment.  And Btrfs is closest to the finish line in that regard.
It needs all the help it can get.

Regards,

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