SCIENTIFIC-LINUX-USERS Archives

April 2017

SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Konstantin Olchanski <[log in to unmask]>
Reply To:
Konstantin Olchanski <[log in to unmask]>
Date:
Tue, 11 Apr 2017 15:26:24 -0700
Content-Type:
text/plain
Parts/Attachments:
text/plain (34 lines)
On Tue, Apr 11, 2017 at 10:47:09PM +0200, David Sommerseth wrote:
> 
> So lets flip this around ... Why isn't btrfs enabled by default in RHEL...
>

I already wrote about BTRFS in this thread. I did some extensive
tests of BTRFS and the performance is quite acceptable (close to hardware
capability, about the same as raid6+xfs), the interesting features
all work, raid5/raid6 is more flexible compared to zfs.

But for production use, they are missing one small feature:

there is no handling whatsoever of disk failures. If you unplug a disk
(or if a disk unplugs itself by giving up the ghost), BTRFS does
absolutely nothing other than filling the syslog with error messages.

Then there are small bugs, for example, if BTRFS is in degraded
mode (one or more dead disk) el7 will not boot (systemd will wait
forever for the missing disk). Suggested workaround do not work,
and this means if one disk dies, you have to manually replace
it and do the rebuild before rebooting. If you do reboot, you will have
to go into single user mode, install the replacement disk,
run the btrfs rebuild, only then you can boot normally. The server
is down all this time.

My conclusion is BTRFS in the "this is a toy" departement,
not in the "this is unstable" or "preview" departement.

-- 
Konstantin Olchanski
Data Acquisition Systems: The Bytes Must Flow!
Email: olchansk-at-triumf-dot-ca
Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada

ATOM RSS1 RSS2