linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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


  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).