Re: [PATCH] BTRFS: Adds an option to select RAID Stripe size

From: Sanidhya Solanki <jpage.lkml@gmail.com>
To: Christoph Anton Mitterer <calestyo@scientia.net>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: [PATCH] BTRFS: Adds an option to select RAID Stripe size
Date: Mon, 28 Dec 2015 21:23:43 -0500	[thread overview]
Message-ID: <20151228212343.449c8631@gmail.com> (raw)
In-Reply-To: <1451368991.7094.45.camel@scientia.net>

On Tue, 29 Dec 2015 07:03:11 +0100
Christoph Anton Mitterer <calestyo@scientia.net> wrote:

> On Mon, 2015-12-28 at 20:31 -0500, Sanidhya Solanki wrote:
> > What is your experience like about running a production system on
> > what
> > is essentially a beta product? Crashes?
> What do you mean? btrfs? I'm not yet running it in production (there
> was a subthread recently, where I've explained a bit more why).

>From Documentation/filesystems/BTRFS.txt:
Btrfs is under heavy development, and is not suitable for
any uses other than benchmarking and review. The Btrfs disk format is
not yet finalized.

> > Would something like ZFS not be more suited to your environment?
> Well I guess that's my personal political decision... I simply think
> that btrfs should and will be the next gen Linux main filesystem.
> Plus that IIRC zfs-fuse is no unmaintained and linux-zfs not yet part
> of Debian rules it anyway out, as I'd be tool lazy to compile it
> myself (at least for work ;) ).

The kernel module "ZFS on Linux" is still actively developed according
to their repo activity (https://github.com/zfsonlinux/zfs). It is done
by a subcontractor for Lawrence Livermore National Laboratory.
Considering they are still in preparation for their Next Generation
Supercomputer (Summit), we can assume that they will keep financing the
development.

> > Especially as not all disks will be full, and, if a disk was to
> > fail, the entire disk would need to be rebuilt from parity drives
> > (as opposed
> > to ZFS only using the parity data, and not copying empty blocks
> > (another feature that is planned for BTRFS))
> Ah? I thought btrfs would already do that as well?

Not yet. Not according to the source code "todo"s atleast.
Thanks for the information about HW RAID controllers.
> I'm not sure what you mean by "cache"... wouldn't btrfs' CoW mean that
> you "just" copy the data, and once this is done, update the metadata
> and things would be either consistent or they would not (and in case
> of a crash still point to the old, not yet reshaped, data)?
> 
> A special case were of course nodatacow'ed data.... there one may need
> some kind of cache or journal... (see the other thread of mine, where
> I ask for checksumming with no-CoWed data =) ).

I just started working recently on BTRFS, I forgot about the CoW part.

Thanks