Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.misc > #1802 > unrolled thread

BTRFS usage?

Back to article view | Back to comp.misc

Contents

  BTRFS usage? Lance Orner <lance@orner.invalid.net> - 2014-03-19 11:42 -0700
    Re: BTRFS usage? Rich <rich@example.com> - 2014-03-19 19:40 +0000
    Re: BTRFS usage? Tim Watts <tw_usenet@dionic.net> - 2014-03-19 21:26 +0000
      Re: BTRFS usage? Johny B Good <johnny-b-good@invalid.ntlworld.com> - 2014-03-20 01:26 +0000
        Re: BTRFS usage? RS Wood <rsw@therandymon.com> - 2014-03-20 09:04 +0000
          Re: BTRFS usage? RS Wood <rsw@therandymon.com> - 2014-03-20 13:09 +0000
            Re: BTRFS usage? "Aaron W. Hsu" <arcfide@sacrideo.us> - 2014-03-20 14:15 -0500

#1802 — BTRFS usage?

Although I'm just using BTRFS for home server useage, I have been
using it for the past year or so, and just recently used to to
assemble a RAID1 configuration, which is really easy to do and
reconfigure.  In casual reading, it seems BTRFS is the future of
filesystems.

However, I also read about scary "experimental" tags, and how people
don't want to commit to it yet.  I guess I can understand full scale
IS deployment risks, but is it ever going to be labled as done and we
move on?

[toc] | [next] | [standalone]

#1804

Lance Orner <lance@orner.invalid.net> wrote:
> Although I'm just using BTRFS for home server useage, I have been
> using it for the past year or so, and just recently used to to
> assemble a RAID1 configuration, which is really easy to do and
> reconfigure.  In casual reading, it seems BTRFS is the future of
> filesystems.

> However, I also read about scary "experimental" tags, and how people
> don't want to commit to it yet.  I guess I can understand full scale
> IS deployment risks, but is it ever going to be labled as done and we
> move on?

Am using BTRFS on two different laptops as the root filesystem, no RAID
settings at all.  So far has performed well in that environment.

Was also using it in a RAID array senario with a bunch of disks a while
back (about a year ago now was the last use of it in that senario).  It
performed just fine in that environment until something started to go
wrong with one of the drives in the array.

Once one of the drives started to have some trouble, all hell broke
lose and BTRFS was not at all happy, or working.  This occurred two
times.  Kernel panics when trying to mount the array.  Massive data
loss.  The BTRFS recovery tool only pulled out a part of the data from
the disks.

After time #2, switched back to ext4 on top of LVM for the raid array. 
Have not had any trouble with ext4/LVM since the switch back.  Have had
two different drives start to go bad in the meantime (ext4 time).  Just
go through the normal LVM/ext4 drive pull/migration, all data remained
safe.  No trouble at all.

So, at the moment my opinion of BTRFS's RAID support is to pay
attentiion to the scary "experimental" tags and respect the fact that
the dev's admit it is "not ready for prime time" yet in that respect.

The reason I'm less worried on the laptops is that as there is only one
drive in each, and only one filesystem, if the single disk starts to go
bad, there's nothing to do but swap out the disk and restore from
backups.  So even if BTRFS panics when the disk starts to go bad, it is
less of a big deal, because there is no other recovery path than
"restore".

In both of the instances where it went bad in the raid array, it was
not "drive failure" (as in whole disk disappears).  It was "drive
starts returning bum data seemingly randomly".  BTRFS did not fare well
at all in that environment.  I suspect it has been tested against the
"pull the plug on disk #3" failure mode, but not adequately for the
"disk #3 begins to return bad data for 2% of read accesses" failure
mode.

[toc] | [prev] | [next] | [standalone]

#1808

On 19/03/14 18:42, Lance Orner wrote:
> Although I'm just using BTRFS for home server useage, I have been
> using it for the past year or so, and just recently used to to
> assemble a RAID1 configuration, which is really easy to do and
> reconfigure.  In casual reading, it seems BTRFS is the future of
> filesystems.
>
> However, I also read about scary "experimental" tags, and how people
> don't want to commit to it yet.  I guess I can understand full scale
> IS deployment risks, but is it ever going to be labled as done and we
> move on?
>

Wouldn't touch it with a bargepole for anything important. I did try it 
once, experimentally - it was not ready for primetime - though that was 
a couple of years back.

However, if you can use it in an experimental context, and can feed back 
to the developers, it's always good.

[toc] | [prev] | [next] | [standalone]

#1814

On Wed, 19 Mar 2014 21:26:28 +0000, Tim Watts <tw_usenet@dionic.net>
wrote:

>On 19/03/14 18:42, Lance Orner wrote:
>> Although I'm just using BTRFS for home server useage, I have been
>> using it for the past year or so, and just recently used to to
>> assemble a RAID1 configuration, which is really easy to do and
>> reconfigure.  In casual reading, it seems BTRFS is the future of
>> filesystems.
>>
>> However, I also read about scary "experimental" tags, and how people
>> don't want to commit to it yet.  I guess I can understand full scale
>> IS deployment risks, but is it ever going to be labled as done and we
>> move on?
>>
>
>Wouldn't touch it with a bargepole for anything important. I did try it 
>once, experimentally - it was not ready for primetime - though that was 
>a couple of years back.
>
>However, if you can use it in an experimental context, and can feed back 
>to the developers, it's always good.

 I've gotten the impression in recent years[1] that "ZFS is where it's
all at" now, seemingly sidelining BTRFS since there are ZFS ports to
Linux in existence.

[1] Probably just the last two years, but it seems to have been "All
The Rage" with a large number of home users running FreeNAS and
NAS4Free servers. I haven't subscribed to this 'latest Fad' yet since
it seems a little bit of an overkill solution for my present
circumstance.

 However, I do like the data integrity and protection strategy options
it has to offer in its ZRAID configurations, particularly in its
absolute insistence on keeping hardware raid completely out of the
picture for best reliability and performance (You just need a wee bit
more ram to get the full benefit - a much cheaper option than
splashing out on a dedicated RAID controller board that may well
become obsoleted in just a few short years).
-- 
Regards, J B Good

[toc] | [prev] | [next] | [standalone]

#1815

On 2014-03-20, Johny B Good <johnny-b-good@invalid.ntlworld.com> wrote:
> [1] Probably just the last two years, but it seems to have been "All
> The Rage" with a large number of home users running FreeNAS and
> NAS4Free servers. I haven't subscribed to this 'latest Fad' yet since
> it seems a little bit of an overkill solution for my present
> circumstance.

Well, I'm a recent FreeNAS owner and though I'm still learning the ropes, i've
got to say ZFS is pretty damn cool.  Take a snapshot, rollback, etc., all with
essentially limitless ability to be scripted and customized.  I'm still
swimming in water over my head, but what I've seen impresses me.

openSUSE now provides BTRFS on its newest release:
http://www.phoronix.com/scan.php?page=news_item&px=MTQ4ODE
http://en.opensuse.org/Features#Under_the_hood

But their caveats don't exactly fill me with confidence it's ready for
primetime.

[toc] | [prev] | [next] | [standalone]

#1818

On 2014-03-20, RS Wood <rsw@therandymon.com> wrote:
> openSUSE now provides BTRFS on its newest release:
> http://www.phoronix.com/scan.php?page=news_item&px=MTQ4ODE
> http://en.opensuse.org/Features#Under_the_hood
>
> But their caveats don't exactly fill me with confidence it's ready for
> primetime.

Lengthy discussion going on about this subject at Slashdot:

Feed: Slashdot
Title: OpenSUSE 13.2 To Use Btrfs By Default
Author: Soulskill
Link: http://rss.slashdot.org/~r/Slashdot/slashdot/~3/Fp9Ay99bFGU/story01.htm
Date: Wed, 19 Mar 2014 17:55:00 -0400

An anonymous reader writes "OpenSUSE has shared features coming to their 13.2
release in November. The big feature is using Btrfs by default instead of
EXT4. OpenSUSE is committed to Btrfs and, surprisingly, they are the first
major Linux distribution to use it by default. But then again, they were also
big ReiserFS fans. Other planned OpenSUSE 13.2 features are Wayland 1.4, KDE
Frameworks 5, and a new Qt5 front-end to YaST."

"http://hardware.slashdot.org/story/14/03/19/2125243/opensuse-132-to-use-btrfs-by-default?utm_source=rss1.0moreanon&utm_medium=feed" 

I was going to say "good discussion ..." but the quality of the comments has
slipped even since I F'ed Beta back in February.

[toc] | [prev] | [next] | [standalone]

#1829

On Thu, 20 Mar 2014 13:09:12 +0000, RS Wood wrote:

> On 2014-03-20, RS Wood <rsw@therandymon.com> wrote:
>> openSUSE now provides BTRFS on its newest release:
>> http://www.phoronix.com/scan.php?page=news_item&px=MTQ4ODE
>> http://en.opensuse.org/Features#Under_the_hood
>>
>> But their caveats don't exactly fill me with confidence it's ready for
>> primetime.
> 
> Feed: Slashdot Title: OpenSUSE 13.2 To Use Btrfs By Default Author:
> Soulskill Link:

I have been using BTRFS on OpenSUSE for a while now, and I'd say that 
OpenSUSE delivers a better BTRFS experience than most of the other 
distributions I have tried, including Slackware and Fedora. They have 
good integration with their tools, and actually make use of the BTRFS 
features in an useful way. The YAST partitioner makes it easy to work 
with the BTRFS systems and the like. 

There are some caveats to keep in mind for the best performance on 
certain drives, however. I've taken note of the ones that mean something 
for me:

http://www.sacrideo.us/btrfs-and-performance-troubles/

-- 
Aaron W. Hsu | arcfide@sacrideo.us | http://www.sacrideo.us
Please support my work: https://www.gittip.com/arcfide/

לֵ֤ב חֲכָמִים֙ בְּבֵ֣ית אֵ֔בֶל וְלֵ֥ב כְּסִילִ֖ים בְּבֵ֥ית שִׂמְחָֽה׃

[toc] | [prev] | [standalone]

Back to top | Article view | comp.misc

csiph-web