From: Christoph Anton Mitterer <calestyo@scientia.net>
To: Btrfs BTRFS <linux-btrfs@vger.kernel.org>
Subject: Re: btrfs
Date: Sun, 05 Jun 2016 22:39:09 +0200 [thread overview]
Message-ID: <1465159149.6702.29.camel@scientia.net> (raw)
In-Reply-To: <CAJCQCtTrrusKs2BeXN5AFBGFzS3zsU2KFSh0pk=DhER7pELzvg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1682 bytes --]
On Sun, 2016-06-05 at 09:51 -0600, Chris Murphy wrote:
> Why is mdadm the reference point for terminology?
I haven't said it is,... I just said it mdadm, original paper, WP use
it the common/historic way.
And since all of these were there before btrfs, and in the case of
mdadm/MD "in" the kernel,... one should probably try to follow that, if
possible.
> There's actually better consistency in terminology usage outside
> Linux
> because of SNIA and DDF than within Linux where the most basic terms
> aren't agreed upon by various upstream maintainers.
Does anyone in the Linux world really care much about DDF? Even
outside? ;-)
Seriously,... as I tried to show in one of my previous posts, I think
the terminology of DDF, at least WRT RAID1 is a bit awkward.
> mdadm and lvm use
> different terms even though they're both now using the same md
> backend
> in the kernel.
Depending on whether one choose to use "raid1" and "mirror" segment
types....
Anyway,... I think that discussion gets a bit pointless,... I think
it's clear that the current terminology may easily cause confusion, and
I think for a term like "RAID1", which is a artificial name it's
something completely else as for terms like "stripe", "chunk", etc.,
which are rather common terms and where one must expect that they are
used for different things in different areas.
And as I've said just before... the other points on my bucket list,
like the UUID collision (security) issues, the no checksumming with
nodatacow, etc. deserve IMHO much more attention than the terminology
:)
So I'm kinda out of this specific part of the discussion.
Cheers,
Chris.
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5930 bytes --]
next prev parent reply other threads:[~2016-06-05 20:39 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-01 22:25 raid5/6 production use status? Christoph Anton Mitterer
2016-06-02 9:24 ` Gerald Hopf
2016-06-02 9:35 ` Hugo Mills
2016-06-02 10:03 ` Gerald Hopf
2016-06-03 17:38 ` btrfs (was: raid5/6) production use status (and future)? Christoph Anton Mitterer
2016-06-03 19:50 ` btrfs Austin S Hemmelgarn
2016-06-04 1:51 ` btrfs Christoph Anton Mitterer
2016-06-04 7:24 ` btrfs Andrei Borzenkov
2016-06-04 17:00 ` btrfs Chris Murphy
2016-06-04 17:37 ` btrfs Christoph Anton Mitterer
2016-06-04 19:13 ` btrfs Chris Murphy
2016-06-04 22:43 ` btrfs Christoph Anton Mitterer
2016-06-05 15:51 ` btrfs Chris Murphy
2016-06-05 20:39 ` Christoph Anton Mitterer [this message]
2016-06-04 21:18 ` btrfs Andrei Borzenkov
2016-06-05 20:39 ` btrfs Henk Slager
2016-06-05 20:56 ` btrfs Christoph Anton Mitterer
2016-06-05 21:07 ` btrfs Hugo Mills
2016-06-05 21:31 ` btrfs Christoph Anton Mitterer
2016-06-05 23:39 ` btrfs Chris Murphy
2016-06-08 6:13 ` btrfs Duncan
2016-06-06 0:56 ` btrfs Chris Murphy
2016-06-06 13:04 ` btrfs Austin S. Hemmelgarn
[not found] ` <f4a9ef2f-99a8-bcc4-5a8f-b022914980f0@swiftspirit.co.za>
2016-06-04 2:13 ` btrfs Christoph Anton Mitterer
2016-06-04 2:36 ` btrfs Chris Murphy
-- strict thread matches above, loose matches on Subject: below --
2024-01-15 15:32 btrfs Turritopsis Dohrnii Teo En Ming
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=1465159149.6702.29.camel@scientia.net \
--to=calestyo@scientia.net \
--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;
as well as URLs for NNTP newsgroup(s).