From: Hugo Mills <hugo-lkml@carfax.org.uk>
To: Anthony Roberts <btrfs-devel@arbitraryconstant.com>
Cc: Hugo Mills <hugo-lkml@carfax.org.uk>, linux-btrfs@vger.kernel.org
Subject: Re: A little confused about what remains to make a stable release
Date: Thu, 18 Nov 2010 09:39:07 +0000 [thread overview]
Message-ID: <20101118093907.GE2401@selene> (raw)
In-Reply-To: <230760eab83b95c53c2ec6e618360a01@arbitraryconstant.com>
[-- Attachment #1: Type: text/plain, Size: 1967 bytes --]
On Wed, Nov 17, 2010 at 05:46:30PM -0700, Anthony Roberts wrote:
> > It's stable *for you* when it functions with the workloads *you*
> >expect of it, with a failure rate that is acceptable *to you*.
>
> I think there's a few ancillary things like a working fsck needed
> before it can even be recommended for widespread use, even to users
> willing to risk any residual bugs. IIRC at this point the utilities
> don't even aspire to provide basic recovery functionality (though
> Chris has posted that fsck is coming).
>
> Beyond that, the management capabilities at this point don't look
> ready for long term use in a production environment. By this I
> mean adding/removing disks,
That much is already there and working.
> reshaping arrays, etc. Without that I
> might use BTRFS on top of LVM/RAID just like any other filesystem,
> and there's features I'm looking forward to even if I that's all
> I can do, but without robust management features there's certain
> environments where it just doesn't make sense yet.
What do you think is missing? Could you create and maintain a
wishlist page on the wiki[1], and populate it with all the things that
people need for production use? (This is an ongoing task -- track
what's actually finished and remove it; track what's currently being
worked on and mark it as such; keep an eye on discussions on the
mailing list for things that people need...)
> There's one or two other things I'm keeping an eye on. That
> limitation on the number of hardlinks you can have in a directory
> is kinda irksome. Also, dedup needs a way to verify/dedup safely
> before people can start doing stuff like deduping live VM images.
Hugo.
[1] https://btrfs.wiki.kernel.org/index.php/Main_Page
--
=== Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk ===
PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
--- Someone's been throwing dead sheep down my Fun Well ---
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 190 bytes --]
next prev parent reply other threads:[~2010-11-18 9:39 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-17 22:27 A little confused about what remains to make a stable release Daniel Farina
2010-11-17 22:59 ` Hugo Mills
2010-11-18 0:46 ` Anthony Roberts
2010-11-18 6:24 ` Daniel Farina
2010-11-18 9:39 ` Hugo Mills [this message]
2010-11-18 18:22 ` Anthony Roberts
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20101118093907.GE2401@selene \
--to=hugo-lkml@carfax.org.uk \
--cc=btrfs-devel@arbitraryconstant.com \
--cc=linux-btrfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.