From: Duncan <1i5t5.duncan@cox.net>
To: linux-btrfs@vger.kernel.org
Subject: Re: mix ssd and hdd in single volume
Date: Fri, 7 Apr 2017 03:12:12 +0000 (UTC) [thread overview]
Message-ID: <pan$cdd2e$cc55a257$d0ed8ef2$bf00097b@cox.net> (raw)
In-Reply-To: 20170403134107.30e923d8@natsu
Roman Mamedov posted on Mon, 03 Apr 2017 13:41:07 +0500 as excerpted:
> On Mon, 3 Apr 2017 11:30:44 +0300 Marat Khalili <mkh@rqc.ru> wrote:
>
>> You may want to look here: https://www.synology.com/en-global/dsm/Btrfs
>> . Somebody forgot to tell Synology, which already supports btrfs in all
>> hardware-capable devices. I think Rubicon has been crossed in
>> 'mass-market NAS[es]', for good or not.
>
> AFAIR Synology did not come to this list asking for (any kind of) advice
> prior to implementing that (else they would have gotten the same kind of
> post from Duncan and others)[.] I don't remember seeing them actively
> contribute improvements or fixes especially for the RAID5 or RAID6
> features (which they ADVERTISE on that page as a fully working part of
> their product).
> That doesn't seem honest to end users or playing nicely with the
> upstream developers. What the upstream gets instead is just those
> end-users coming here one by one some years later, asking how to fix
> a broken Btrfs RAID5 on an embedded box running some 3.10 or 3.14
> kernel.
And of course then the user gets the real state of btrfs and of btrfs
raid56 mode, particularly back that far, explained to them. Along with
that we'll explain that any data on it is in all likelihood lost data,
with little to no chance at recovery.
And we'll point out that if there was serious value in the data, they
would have investigated the state of the filesystem before they put that
data on it, and of course, as I've already said, they'd have had backups
for anything that was of more value than the time/resources/hassle of
doing those backups.
And if they're lucky, that NAS will have /been/ the backup, and they'll
still have the actual working copy at least, and can make another backup
ASAP just in case that working copy dies too.
But if they're unlucky...
Of course the user will then blame the manufacturer, but by that time the
warranty will be up, and even if not, while they /might/ get their money
back, that won't get their data back.
And the manufacturer will get a bad name, but by then having taken the
money and run they'll be on to something else or perhaps be bought out by
someone bigger or be out of business.
And all the user will be able to do is chalk it up to experience, and
mourn the loss of their kids' baby pictures/videos or their wedding
videos, or whatever. If they're /really/ lucky, they'll have put them on
facebook or youtube or whatever, and can retrieve at least those, from
there.
Meanwhile, the user, having been once burned, may never use the by then
much improved btrfs, or even worse, never trust anything Linux, again.
Oh, well. The best we can do here is warn those that /do/ value their
data enough to do their research first, so they /do/ have those backups
or at least use something a bit more mature than btrfs raid56 mode. Of
course and continue to work on full btrfs stabilization. And I like to
think we're reasonably good at those warnings, anyway. The
stabilization, too, but that takes time and patience, plus coder skill,
the last of which which I personally don't have, so I just pitch in where
I can, answering questions, etc.
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
next prev parent reply other threads:[~2017-04-07 3:12 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-01 6:06 mix ssd and hdd in single volume UGlee
2017-04-02 0:13 ` Duncan
2017-04-03 8:30 ` Marat Khalili
2017-04-03 8:41 ` Roman Mamedov
2017-04-07 3:12 ` Duncan [this message]
2017-04-03 12:23 ` Austin S. Hemmelgarn
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='pan$cdd2e$cc55a257$d0ed8ef2$bf00097b@cox.net' \
--to=1i5t5.duncan@cox.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).