From: Martin <m_btrfs@ml1.co.uk>
To: linux-btrfs@vger.kernel.org
Subject: Re: ditto blocks on ZFS
Date: Thu, 22 May 2014 00:05:26 +0100 [thread overview]
Message-ID: <lljbfo$6vm$1@ger.gmane.org> (raw)
In-Reply-To: <1795587.Ol58oREtZ7@xev>
Very good comment from Ashford.
Sorry, but I see no advantages from Russell's replies other than for a
"feel-good" factor or a dangerous false sense of security. At best,
there is a weak justification that "for metadata, again going from 2% to
4% isn't going to be a great problem" (storage is cheap and fast).
I thought an important idea behind btrfs was that we avoid by design in
the first place the very long and vulnerable RAID rebuild scenarios
suffered for block-level RAID...
On 21/05/14 03:51, Russell Coker wrote:
> Absolutely. Hopefully this discussion will inspire the developers to
> consider this an interesting technical challenge and a feature that
> is needed to beat ZFS.
Sorry, but I think that is completely the wrong reasoning. ...Unless
that is you are some proprietary sales droid hyping features and big
numbers! :-P
Personally I'm not convinced we gain anything beyond what btrfs will
eventually offer in any case for the n-way raid or the raid-n Cauchy stuff.
Also note that usually, data is wanted to be 100% reliable and
retrievable. Or if that fails, you go to your backups instead. Gambling
"proportions" and "importance" rather than *ensuring* fault/error
tolerance is a very human thing... ;-)
Sorry:
Interesting idea but not convinced there's any advantage for disk/SSD
storage.
Regards,
Martin
next prev parent reply other threads:[~2014-05-21 23:05 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-16 3:07 ditto blocks on ZFS Russell Coker
2014-05-17 12:50 ` Martin
2014-05-17 14:24 ` Hugo Mills
2014-05-18 16:09 ` Russell Coker
2014-05-19 20:36 ` Martin
2014-05-19 21:47 ` Brendan Hide
2014-05-20 2:07 ` Russell Coker
2014-05-20 14:07 ` Austin S Hemmelgarn
2014-05-20 20:11 ` Brendan Hide
2014-05-20 14:56 ` ashford
2014-05-21 2:51 ` Russell Coker
2014-05-21 23:05 ` Martin [this message]
2014-05-22 11:10 ` Austin S Hemmelgarn
2014-05-22 22:09 ` ashford
2014-05-23 3:54 ` Russell Coker
2014-05-23 8:03 ` Duncan
2014-05-21 23:29 ` Konstantinos Skarlatos
-- strict thread matches above, loose matches on Subject: below --
2014-05-22 15:28 Tomasz Chmielewski
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='lljbfo$6vm$1@ger.gmane.org' \
--to=m_btrfs@ml1.co.uk \
--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.