|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 …|
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  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/  Lee -------------------------FROM: "Joe Rosato" <firstname.lastname@example.org> TO: "Philadelphia Linux User's Group Discussion List" <email@example.com> 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 <firstname.lastname@example.org> wrote:On Sat, Jan 31, 2015 at 2:21 PM, Lee H. Marzke <email@example.com> wrote:So your solution on Vmware could be a vAPP composed of virtualstorage /NAS VM running OpenIndiana or FreeBSD, and and a teacher VM Linux desktop. Thestudentscan connect Linux desktops / VM's via NFS to the NAS storage. ThevApp couldrun from a VM Workstation on a Laptop with SSD, or vSphereThe 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-- "Between subtle shading and the absence of light lies the nuance of iqlusion..." - Kryptos Lee Marzke, firstname.lastname@example.org 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://email@example.com VOIP Links: ------  http://www.phillylinux.org  http://lists.phillylinux.org/mailman/listinfo/plug-announce  http://lists.phillylinux.org/mailman/listinfo/plug  http://ddurdle.blogspot.com/2014/12/btrfs-one-year-later.html  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