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: Moving top level to a subvolume
Date: Wed, 13 Jun 2012 17:17:50 +0000 (UTC)	[thread overview]
Message-ID: <pan.2012.06.13.17.17.50@cox.net> (raw)
In-Reply-To: CAG1y0setJcXT-ncyvQJhCeSdfRKXksx9azVHih7Tpe6UxGkMgQ@mail.gmail.com

Fajar A. Nugraha posted on Wed, 13 Jun 2012 16:08:40 +0700 as excerpted:

>> My system's old and has a bit of a problem with overheating in the
>> Phoenix summer, so has been suffering SATA resets
> 
>> it's exactly this sort of corner-case that filesystems need to be able
>> to deal with
> 
> IIRC XFS had corruption problems when used on top of LVM (or other block
> device that doesn't support barriers correctly), while using ext2/3/4 on
> the same block device will be "fine". Yet XFS doesn't have the mark of
> "unstable, highly experimental, do not use". People simply use the right
> (for them) fs for the right job.

It /does/ have a reputation of "don't use for a normal home system or 
other location without a suitably dependable UPS on fully stable 
hardware", however.  (From what I've read however, much like reiserfs has 
been for me here after data=ordered, xfs is vastly improved now, and said 
reputation likely no longer applies.)

If btrfs is to replace ext3/4, then that sort of reputation isn't what 
its devs will be shooting for.  We have at least the two filesystems 
(reiserfs and xfs) with serious reputation problems from their earlier 
life, and my big concern is that if enough people fail to consider btrfs' 
current development state and end up with data loss as a result, btrfs 
will end up with a very similar reputation, which will similarly live 
many years longer than the reality that created it.  But the other two 
weren't shooting for the ext* mantle, and btrfs is.  If its reputation is 
damaged to that extent and it becomes the assumed Linux default as ext3/4 
is now, that will be the Linux reputation.

> My point is yes, btrfs is new. And it's being developed at much faster
> rate than any other more-mature fs out there. And there are known cases
> of data loss on certain configuration of corner cases/"buggy" hardware
> and/or old version of kernel. But when used in the correct environment,
> btrfs can be a good choice, even for critical data.

Of course, critical data is backed up, or by definition you don't REALLY 
consider it so critical after all.  (There was a time when drives were 
small enough and expensive enough, as were the alternatives, that wasn't 
the case.  That time is long gone, for first and second world usage, 
anyway.  Even a home user with a single drive can split it into multiple 
partitions, with backup data on separate partitions, at least, with the 
real critical data on a thumb-drive too.)

But while people can and do unfortunately go without backups and are 
often lucky, doing so on btrfs at this stage in its development is 
"doubly insane", to channel Linus (actually being nice that day =:^) 
describing a recent commit, in his revert.

But there's obviously "doubly insane" people out there! =:^\

> Of course IF the data were REALLY critical, and I REALLY need btrfs'
> features, and it were on an enterprise environment, I would've bought
> support from oracle linux (or SLES 12, when it's out, or whatever
> enterprise distro supporting btrfs which sells support contract) so I
> can have someone to turn to in case of problems, and (in some cases)
> transfer the risk/blame :D

That's a good point.  Of course, as many people find out, such "support" 
often /does/ really come down to "someone else to blame".  Yes, they'll 
help with recovery if it comes to it, but if your $100K+ an hour business 
is down in the mean time... and you didn't have those backups and at 
/least/ "cold" failover... they'll be finding someone to blame as well!

-- 
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:[~2012-06-13 17:18 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-08 19:24 Moving top level to a subvolume Matthew Hawn
2012-06-08 19:40 ` Arne Jansen
2012-06-13  7:04   ` C Anthony Risinger
2012-06-13  7:21     ` Arne Jansen
2012-06-13  9:44       ` C Anthony Risinger
2012-06-13  9:57         ` Fajar A. Nugraha
2012-06-13 16:20       ` Goffredo Baroncelli
2012-06-12  1:53 ` Duncan
2012-06-12 14:52   ` Randy Barlow
2012-06-12 15:12     ` Michael
2012-06-13  1:49     ` Fajar A. Nugraha
2012-06-13  7:23       ` Duncan
2012-06-13  9:08         ` Fajar A. Nugraha
2012-06-13 17:17           ` Duncan [this message]

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