From: Austin S Hemmelgarn <ahferroin7@gmail.com>
To: Shriramana Sharma <samjnaa@gmail.com>,
linux-btrfs <linux-btrfs@vger.kernel.org>
Subject: Re: Significance of high number of mails on this list?
Date: Fri, 22 Aug 2014 07:43:57 -0400 [thread overview]
Message-ID: <53F72CFD.1060702@gmail.com> (raw)
In-Reply-To: <CAH-HCWVZPNkc7ycsL4jH0i6niVU3nqZiB2MLD6CfP85FckAg7g@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2023 bytes --]
On 2014-08-20 23:22, Shriramana Sharma wrote:
> Hello. People on this list have been kind enough to reply to my
> technical questions. However, seeing the high number of mails on this
> list, esp with the title PATCH, I have a question about the
> development itself:
>
> Is this just an indication of a vibrant user/devel community [*] and
> healthy development of many new nice features to eventually come out
> in stable form later, or are we still at the fixing rough edges stage?
> IOW what is the proportion of commits adding new features to those
> stabilising/fixing features?
>
> [* Since there is no separate btrfs-users vs brtfs-dev I'm not able to
> gauge this difference either. i.e. if there were a dedicated -dev list
> I might not be alarmed by a high number of mails indicating fast
> development.]
>
> Mostly I have read like "BTRFS is mostly stable but there might be a
> few corner cases as yet unknown since this is a totally new generation
> of FSs". But still given the volume of mails here I wanted to ask...
> I'm sorry I realize I'm being a bit vague but I'm not sure how to
> exactly express what I'm feeling about BTRFS right now...
>
Personally I'd say that BTRFS is 'stable' enough for light usage without
using stuff like quotas or RAID5/6. So far, having used it since 3.10,
I've only once had a filesystem get corrupted when there wasn't some
serious underlying hardware issue (crashed disk, SATA controller
dropping random single sectors from writes, etc.), and it gives me much
better performance than what I previously used (ext4 on top of LVM).
As far as what to make of the volume of patches on the mailing list, I'd
say that that shouldn't be used as a measure of quality. The ext4
mailing list is almost as busy on a regular basis, and people have been
using that in production for years, and the XFS mailing list gets much
higher volume of patches from time to time, and it's generally
considered the gold standard of a stable filesystem.
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 2455 bytes --]
prev parent reply other threads:[~2014-08-22 11:44 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-21 3:22 Significance of high number of mails on this list? Shriramana Sharma
2014-08-21 9:14 ` Duncan
2014-08-21 11:11 ` Martin Steigerwald
2014-08-22 3:40 ` Shriramana Sharma
2014-08-22 4:19 ` Marc MERLIN
2014-08-22 6:56 ` Konstantinos Skarlatos
2014-08-22 7:35 ` Duncan
2014-08-22 9:58 ` Filipe David Manana
2014-08-22 13:13 ` Konstantinos Skarlatos
2014-08-22 17:35 ` Duncan
2014-08-22 18:34 ` Rich Freeman
2014-08-22 13:15 ` Marc MERLIN
2014-08-22 11:43 ` Austin S Hemmelgarn [this message]
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=53F72CFD.1060702@gmail.com \
--to=ahferroin7@gmail.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=samjnaa@gmail.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).