From: Wilson Meier <wilson.meier@gmail.com>
To: Btrfs BTRFS <linux-btrfs@vger.kernel.org>
Subject: Re: Convert from RAID 5 to 10
Date: Thu, 1 Dec 2016 10:37:13 +0100 [thread overview]
Message-ID: <668d0396-e0aa-8f67-f96a-490924175bb9@googlemail.com> (raw)
In-Reply-To: <21e6765c-21f9-1726-b06f-9bd5f67c7b49@gmail.com>
Am 30/11/16 um 17:48 schrieb Austin S. Hemmelgarn:
> On 2016-11-30 10:49, Wilson Meier wrote:
>> Am 30/11/16 um 15:37 schrieb Austin S. Hemmelgarn:
>>
>> Transferring this to car analogy, just to make it a bit more funny:
>> The airbag (raid level whatever) itself is ok but the micro controller
>> (general btrfs) which has the responsibility to inflate the airbag is
>> suffers some problems, sometimes doesn't inflate and the manufacturer
>> doesn't mention about that fact.
>> From your point of you the airbag is ok. From my point of view -> Don't
>> buy that car!!!
>> Don't you mean that the fact that the live safer suffers problems should
>> be noted and every dependent component should point to that fact?
>> I think it should.
>> I'm not talking about performance issues, i'm talking about data loss.
>> Now the next one can throw in "Backups, always make backups!".
>> Sure, but backup is backup and raid is raid. Both have their own
>> concerns.
> A better analogy for a car would be something along the lines of the
> radio working fine but the general wiring having issues that cause all
> the electronics in the car to stop working under certain
> circumstances. In that case, the radio itself is absolutely OK, but it
> suffers from issues caused directly by poor design elsewhere in the
> vehicle.
Ahm, no. You cannot exchange a security mechanism (raid) with a comfort
one (compression) and treat them as the same in terms of importance.
It makes a serious difference to have a not properly working airbag or
not being able to listen to music while your a driving against a wall.
Anyway, we should stop this here.
>>>> I'm not angry or something like that :) .
>>>> I just would like to have the possibility to read such information
>>>> about
>>>> the storage i put my personal data (> 3 TB) on its official wiki.
> There are more places than the wiki to look for info about BTRFS (and
> this is the case about almost any piece of software, not just BTRFS,
> very few things have one central source for everything). I don't mean
> to sound unsympathetic, but given what you're saying, it's sounding
> more and more like you didn't look at anything beyond the wiki and
> should have checked other sources as well.
This is your assumption.
Am 01/12/16 um 07:47 schrieb Duncan:
> Austin S. Hemmelgarn posted on Wed, 30 Nov 2016 11:48:57 -0500 as
> excerpted:
>> On 2016-11-30 10:49, Wilson Meier wrote:
>>> Do you also have all home users in mind, which go to vacation (sometime
>>>> 3 weeks) and don't have a 24/7 support team to replace monitored disks
>>> which do report SMART errors?
>> Better than 90% of people I know either shut down their systems when
>> they're going to be away for a long period of time, or like me have
>> ways to log in remotely and tell the FS to not use that disk anymore.
> https://btrfs.wiki.kernel.org/index.php/Getting_started ... ... has
> two warnings offset in red right in the first section: * If you have
> btrfs filesystems, run the latest kernel.
I do. Ok not the very latest but i'm always on the latest major version.
Right now i have 4.8.4 and the very latest is 4.8.11.
> * You should keep and test backups of your data, and be prepared to use
> them.
I have daily backups.
> As to the three weeks vacation thing... And "daily use" != "three
> weeks without physical access to something you're going to actually be
> relying on for parts of those three weeks".
>
Maybe i have my own mailserver and owncloud to server files to my
family? Maybe i'm out of country and somewhere i have no internet access?
I will not comment this any further as it leads us nowhere.
In general i think that this discussion is taking a complete wrong
direction.
The only thing i have asked for is to document the *known*
problems/flaws/limitations of all raid profiles and link to them from
the stability matrix.
Regarding raid10:
Even if one knows about the fact that btrfs handles things on chunk
level one would assume that the code is written in a way to put the
copies on different stripes.
Otherwise raid10 ***can*** become pretty useless in terms of data
redundancy and 2 x raid1 with an lvm should be considered as a replacement.
This is a serious thing and should be documented. If this is documented
somewhere then please point me to it as i cannot find a word about that
anywhere.
Cheers,
Wilson
next prev parent reply other threads:[~2016-12-01 9:37 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-29 17:20 Convert from RAID 5 to 10 Florian Lindner
2016-11-29 17:54 ` Austin S. Hemmelgarn
2016-11-29 22:34 ` Wilson Meier
2016-11-29 22:52 ` Chris Murphy
2016-11-29 23:16 ` Wilson Meier
2016-11-29 23:49 ` Chris Murphy
2016-11-29 23:58 ` Wilson Meier
2016-11-30 5:38 ` Roman Mamedov
2016-11-30 8:06 ` Martin Steigerwald
2016-11-30 8:35 ` Wilson Meier
2016-11-30 10:41 ` Duncan
2016-11-30 13:12 ` Wilson Meier
2016-11-30 14:37 ` Austin S. Hemmelgarn
2016-11-30 15:49 ` Wilson Meier
2016-11-30 16:35 ` Martin Steigerwald
2016-11-30 16:48 ` Austin S. Hemmelgarn
2016-12-01 6:47 ` Duncan
2016-12-01 9:37 ` Wilson Meier [this message]
2016-12-01 11:36 ` Niccolò Belli
2016-11-30 19:09 ` Chris Murphy
2016-11-30 19:36 ` Martin Steigerwald
2016-11-30 20:29 ` Tomasz Kusmierz
2016-12-01 17:28 ` Chris Murphy
2016-12-01 21:40 ` Tomasz Kusmierz
2016-11-30 16:09 ` Niccolò Belli
2016-11-30 12:50 ` Austin S. Hemmelgarn
2016-11-30 14:04 ` Roman Mamedov
2016-11-30 15:43 ` Austin S. Hemmelgarn
2016-11-30 18:59 ` Chris Murphy
2016-11-29 19:03 ` Lionel Bouton
2016-11-29 19:41 ` Austin S. Hemmelgarn
2016-12-06 14:14 ` Florian Lindner
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=668d0396-e0aa-8f67-f96a-490924175bb9@googlemail.com \
--to=wilson.meier@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;
as well as URLs for NNTP newsgroup(s).