K.S. Bhaskar on 31 Jan 2015 11:58:02 -0800


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

Re: [PLUG] zfs vs btrfs vs …


Thanks, Rich. I want to create a virtual machine with instructions that instructors can just download and use.  If btrfs allows me to put read-write snapshots, that solves my problem.  I can make the virtual disk as large as I want, so that it doesn't run out of space.

We don't support NFS for the database.  It's semantics have proved to be less than robust, so we don't support it.

I'll try btrfs and report back.  This is a background project that I want to work on over the next couple of months.

Regards
-- Bhaskar



On Sat, Jan 31, 2015 at 2:48 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
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