[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <49665EC5.2090707@hp.com>
Date: Thu, 08 Jan 2009 15:15:01 -0500
From: jim owens <jowens@...com>
To: Chris Mason <chris.mason@...cle.com>
CC: linux-kernel@...r.kernel.org,
linux-fsdevel <linux-fsdevel@...r.kernel.org>,
linux-btrfs <linux-btrfs@...r.kernel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Andi Kleen <andi@...stfloor.org>,
Ryusuke Konishi <ryusuke@...g.net>
Subject: Re: Btrfs for mainline
Chris Mason wrote:
>
> Unresolved from this reviewing thread:
>
> * Should it be named btrfsdev? My vote is no, it is extra work for the
> distros when we finally do rename it, and I don't think btrfs really has
> the reputation for stability right now. But if Linus or Andrew would
> prefer the dev on there, I'll do it.
We know who has the last word on this.
This is just additional background for those who commented.
Using tricks such as btrfsdev, mount "unsafe", or kernel
messages won't provide a guarantee that btrfs is only used
in appropriate and risk-free ways. Those tricks also won't
prevent all problems caused by booting a broken old (or new)
release. And the perceived quality and performance of any
filesystem release, even between stable versions, depends
very much on individual system configuration and use.
Before Chris posted the code, we had some btrfs concall
discussions about the best way to set user expectations on
btrfs mainline 1.0. Consensus was that the best way we
could do this was to warn them when they did mkfs.btrfs.
Today I sent a patch to Chris (which he may ignore/change)
so mkfs.btrfs will say:
WARNING! - Btrfs v0.16-39-gf9972b4 IS EXPERIMENTAL
WARNING! - see http://btrfs.wiki.kernel.org before using
with a blank line before and after. They don't have to
confirm since they can just mkfs a different filesystem
if I scared them away. The version is auto-generated.
jim
--
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