Joe Rosato on 31 Jan 2015 11:59:56 -0800

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

Re: [PLUG] zfs vs btrfs vs …

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


On Sat Jan 31 2015 at 2:48:27 PM Rich Freeman <> wrote:
On Sat, Jan 31, 2015 at 2:21 PM, Lee H. Marzke <> 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

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.

Philadelphia Linux Users Group         --
Announcements -
General Discussion  --
Philadelphia Linux Users Group         --
Announcements -
General Discussion  --