From: Hugo Mills <hugo@carfax.org.uk>
To: Gandalf Corvotempesta <gandalf.corvotempesta@gmail.com>
Cc: "Austin S. Hemmelgarn" <ahferroin7@gmail.com>,
linux-btrfs@vger.kernel.org
Subject: Re: status page
Date: Wed, 25 Apr 2018 12:45:27 +0000 [thread overview]
Message-ID: <20180425124527.GA7776@carfax.org.uk> (raw)
In-Reply-To: <CAJH6TXg3+j5g8Wk7jo5YM2dvTjvmp8Ddu2u0_v-u8r6agjRnLQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2009 bytes --]
On Wed, Apr 25, 2018 at 02:30:42PM +0200, Gandalf Corvotempesta wrote:
> 2018-04-25 13:39 GMT+02:00 Austin S. Hemmelgarn <ahferroin7@gmail.com>:
> > Define 'stable'.
>
> Something ready for production use like ext or xfs with no critical
> bugs or with easy data loss.
>
> > If you just want 'safe for critical data', it's mostly there already
> > provided that your admins and operators are careful. Assuming you avoid
> > qgroups and parity raid, don't run the filesystem near full all the time,
> > and keep an eye on the chunk allocations (which is easy to automate with
> > newer kernels), you will generally be fine. We've been using it in
> > production where I work for a couple of years now, with the only issues
> > we've encountered arising from the fact that we're stuck using an older
> > kernel which doesn't automatically deallocate empty chunks.
>
> For me, RAID56 is mandatory. Any ETA for a stable RAID56 ?
> Is something we should expect this year, next year, next 10 years, .... ?
There's not really any ETAs for anything in the kernel, in general,
unless the relevant code has already been committed and accepted (when
it has a fairly deterministic path from then onwards). ETAs for
finding even known bugs are pretty variable, depending largely on how
easily the bug can be reproduced by the reporter and by the developer.
As for a stable version -- you'll have to define "stable" in a way
that's actually measurable to get any useful answer, and even then,
see my previous comment about ETAs.
There have been example patches in the last few months on the
subject of closing the write hole, so there's clear ongoing work on
that particular item, but again, see the comment on ETAs. It'll be
done when it's done.
Hugo.
--
Hugo Mills | Nothing wrong with being written in Perl... Some of
hugo@... carfax.org.uk | my best friends are written in Perl.
http://carfax.org.uk/ |
PGP: E2AB1DE4 | dark
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
next prev parent reply other threads:[~2018-04-25 12:45 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-19 16:24 status page Gandalf Corvotempesta
2018-04-23 15:16 ` David Sterba
2018-04-25 11:13 ` Gandalf Corvotempesta
2018-04-25 11:39 ` Austin S. Hemmelgarn
2018-04-25 12:30 ` Gandalf Corvotempesta
2018-04-25 12:45 ` Hugo Mills [this message]
2018-04-25 19:28 ` Duncan
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=20180425124527.GA7776@carfax.org.uk \
--to=hugo@carfax.org.uk \
--cc=ahferroin7@gmail.com \
--cc=gandalf.corvotempesta@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox