From patchwork Thu Feb 21 21:56:02 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: David Sterba X-Patchwork-Id: 2173371 Return-Path: X-Original-To: patchwork-linux-btrfs@patchwork.kernel.org Delivered-To: patchwork-process-083081@patchwork1.kernel.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by patchwork1.kernel.org (Postfix) with ESMTP id 527703FE37 for ; Thu, 21 Feb 2013 21:56:11 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753709Ab3BUV4H (ORCPT ); Thu, 21 Feb 2013 16:56:07 -0500 Received: from cantor2.suse.de ([195.135.220.15]:59990 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753022Ab3BUV4F (ORCPT ); Thu, 21 Feb 2013 16:56:05 -0500 Received: from relay1.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 2B458A38EA; Thu, 21 Feb 2013 22:56:03 +0100 (CET) Received: by ds.suse.cz (Postfix, from userid 10065) id E77DDDB414; Thu, 21 Feb 2013 22:56:02 +0100 (CET) Date: Thu, 21 Feb 2013 22:56:02 +0100 From: David Sterba To: Bardur Arantsson Cc: linux-btrfs@vger.kernel.org Subject: Re: Another defrag question Message-ID: <20130221215602.GH27541@twin.jikos.cz> Reply-To: dsterba@suse.cz Mail-Followup-To: dsterba@suse.cz, Bardur Arantsson , linux-btrfs@vger.kernel.org References: <51264146.3070504@petaramesh.org> <1361462073.18057.23.camel@cwalton-XPS-8300> <512644DA.3050409@petaramesh.org> <20130221163844.GD14283@carfax.org.uk> <51265355.1020409@petaramesh.org> <20130221172502.GF14283@carfax.org.uk> <51265DB0.2060407@petaramesh.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2011-07-01) Sender: linux-btrfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org On Thu, Feb 21, 2013 at 09:58:16PM +0100, Bardur Arantsson wrote: > On 02/21/2013 06:47 PM, Swâmi Petaramesh wrote: > > Le 21/02/2013 18:25, Hugo Mills a écrit : > >> Correct. But btrfs isn't at that stage yet. It's getting visibly > >> closer, but it's not quite there. Hence the very strong recommendation > >> to keep up with the latest code. Hugo. > > > > The matter is that BTRFS had many early adopters just because it is - > > and has been for long now - in the mainline Linux kernel, so supposed > > stable and good choice for the future. > > > > To be honest (and not wanting to troll, promised) this is the only > > single reason for which I use BTRFS on 5 of my 6 machines at home - just > > because I thought that "Just upgrade the distro every 6 months and it > > will become better and better over time, no hassle, make my life easy". > > > > Unfortunately many distros don't make it obvious, but Btrfs is still > hidden behind a giant EXPERIMENTAL label in the kernel configuration. Removed in 3.9-rc1 as a part of a broad Kconfig cleanup http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=38db331b578005d32155bb6f6a80654ef127cff5 The CONFIG_EXPERIMENTAL config item has not carried much meaning for a while now and is almost always enabled by default. As agreed during the Linux kernel summit, remove it from any "depends on" lines in Kconfigs. --- is it still experimental then? -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html --- a/fs/btrfs/Kconfig +++ b/fs/btrfs/Kconfig @@ -1,6 +1,5 @@ config BTRFS_FS - tristate "Btrfs filesystem (EXPERIMENTAL) Unstable disk format" - depends on EXPERIMENTAL + tristate "Btrfs filesystem Unstable disk format" select LIBCRC32C select ZLIB_INFLATE select ZLIB_DEFLATE