R. McIntosh on 31 Jan 2015 13:18:28 -0800


[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

Re: [PLUG] zfs vs btrfs vs …

The linked article seems to be a bit out of date. It certainly pre-dates the declaration of BTRFS's on disk format being stable as of this August, and it also seems to largely to be based in the author's own admitted user error.
I think the instability of BTRFS is being *vastly* overstated in this thread. I certainly wouldn't use it on a major production server, but for common usage it is completely stable in my experience, having been using it as a daily driver for quite some time now. I honestly would consider the notion that you need to be *very* careful when using BTRFS to be somewhat FUD. You should be as careful as anytime you're doing filesystem work, IMHO. df certainly has some issues, largely with RAID, on BTRFS but I wouldn't necessarily say it "basically doesn't work". It's certainly reporting accurate information on my laptop right now, for example.
Mostly, I just think BTRFS is quite a bit more stable than it's being given credit for in this particular thread. 

Richie

On 2015-01-31 15:45, Lee H. Marzke wrote:

ZFS has been out 10 years to so and finally quite stable in the
open-source versions.

BTFS has been out 7 years, and still not production stable. Be very
careful.

Keep multiple copies ( not snapshots) via cloning to another FS or
replication.

http://ddurdle.blogspot.com/2014/12/btrfs-one-year-later.html [4]

at 42:30 Positive review of BTFS with some edge cases:

example: df ( show free file space ) basically doesn't work and the
dev's don't know how to fix it

files with a lot of random writes fragment the filesystem badly.

http://www.jupiterbroadcasting.com/61572/preventing-a-btrfs-nightmare-las-320/
[5]

Lee

-------------------------


FROM: "Joe Rosato" <rosatoj@gmail.com>
TO: "Philadelphia Linux User's Group Discussion List"
<plug@lists.phillylinux.org>
SENT: Saturday, January 31, 2015 2:59:50 PM
SUBJECT: Re: [PLUG] zfs vs btrfs vs …

If going with btrfs make sure to leave enough extra room.
The COW has bitten many people. ;-)

Joe

On Sat Jan 31 2015 at 2:48:27 PM Rich Freeman
<r-plug@thefreemanclan.net> wrote:


On Sat, Jan 31, 2015 at 2:21 PM, Lee H. Marzke <lee@marzke.net>
wrote:

So your solution on Vmware could be a vAPP composed of virtual

storage /

NAS VM running
OpenIndiana or FreeBSD, and and a teacher VM Linux desktop. The

students

can
connect Linux desktops / VM's via NFS to the NAS storage. The

vApp could

run from
a VM Workstation on a Laptop with SSD, or vSphere


The issue I see with this kind of solution is that you still need
to
have a way of mounting all those home directories, which was the
problem that was originally raised with btrfs. If you have an
automounting solution for nfs then you could also use it for
btrfs
(though below I'll go into why this probably isn't necessary to
use
btrfs).

Keep in mind that nfs is almost entirely insecure unless you're
using
nfsv4, which from what I understand is fairly tricky to set up
(I'd
love to hear a PLUG talk on NFS v4, btw). You could use samba,
but
then it isn't POSIX.

If you did want to use btrfs I'd just make /home a btrfs
filesystem
and make all the user directories subvolumes (snapshots of
master) in
each. Then you just put /home in your fstab and you're done -
subvolumes/snapshots just behave like ordinary directories for
the
most part.

The main issue with using btrfs in something for production use
is the
general stability. You'd want to ensure it never got too full,
and
occasionally balance it if you're running out of chunks.
Honestly,
I'm not sure that even I would want to deploy it in this manner
with
clients unless it were something I was investing in as a
"product" of
some sort (ie I put the time in to really bulletproof it,
automate it,
etc). Btrfs really isn't in a state where you can just fire and
forget like you could with mdadm+lvm+ext4, and as Lee has pointed
out
from a legal perspective using zfs on linux in something
commercially
distributed is problematic (you might be able to get around that
if
you're careful - if you don't make copies of binary versions of
it you
may be fine - so if you build every install kernel module from
source
you might be ok, maybe - was that enough "mights" for you?).

If you can handle the nfs then the FreeNAS solution might be the
cleanest option. Sticking a bunch of disks in a NAS box and not
touching them other than replacing failed drives is a pretty
rock-solid use for zfs.

--
Rich




___________________________________________________________________________

Philadelphia Linux Users Group -- http://www.phillylinux.org [1]
Announcements -
http://lists.phillylinux.org/mailman/listinfo/plug-announce [2]
General Discussion --
http://lists.phillylinux.org/mailman/listinfo/plug [3]




___________________________________________________________________________

Philadelphia Linux Users Group -- http://www.phillylinux.org
Announcements -
http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion --
http://lists.phillylinux.org/mailman/listinfo/plug


--

"Between subtle shading and the absence of light lies the nuance of
iqlusion..." - Kryptos

Lee Marzke, lee@marzke.net http://marzke.net/lee/
IT Consultant, VMware, VCenter, SAN storage, infrastructure, SW CM
+1 800-393-5217 office +1 484-348-2230 fax
+1 610-564-4932 cell sip://8003935217@4aero.com VOIP



Links:
------
[1] http://www.phillylinux.org
[2] http://lists.phillylinux.org/mailman/listinfo/plug-announce
[3] http://lists.phillylinux.org/mailman/listinfo/plug
[4] http://ddurdle.blogspot.com/2014/12/btrfs-one-year-later.html
[5]
http://www.jupiterbroadcasting.com/61572/preventing-a-btrfs-nightmare-las-320/

___________________________________________________________________________
Philadelphia Linux Users Group -- http://www.phillylinux.org Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce General Discussion -- http://lists.phillylinux.org/mailman/listinfo/plug 
___________________________________________________________________________
Philadelphia Linux Users Group         --        http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion  --   http://lists.phillylinux.org/mailman/listinfo/plug