On Fri, 5 Jun 2015 05:05:21 PM Serge Hallyn wrote: > > > > Does this mean that btrfs is considered a second class option > > > > > > It is, for a few reasons. > > > > Sorry to persist with this but would you mind elaborating briefly on > > some of those reasons or point me to further discussion please? > > We didn't want to depend on a single fs. Also, btrfs still has some > performance issues (esp at fsync, which kills apt-get),
I suspect a lot of performance issues revolve around unbalanced systems. > and people still seem to hit corruption with it (though other people > seem to run it rock-solid with no issues). Older war stories mostly revolve around folks letting their btrfs systems get to 100% full and/or involve earlier series 3 kernels and those earlier bad experiences are still being used as a reason why btrfs is "not ready". > > I have invested heavily in btrfs so I am a little "shocked" at this > > news. If I want to stick to btrfs then would I be better off relying > > on legacy lxc? > > I don't think we'll be dropping the support we have. Sure, I wouldn't expect that, but it means that most future devel, testing, tutorials and example setups will be based on LVM instead of btrfs and that concerns me (not that my concerns matter in the real world.) > We definately won't be adding support for zfs, overlayfs, etc. Good. > Can you say a bit more about how your usage depends on btrfs? I can't compare btrfs to LVM because I've been using btrfs for so long now that I have forgotten all I knew about LVM... and very glad of that because btrfs is so much simpler and more flexible. I have a couple of dozen personal and professional systems and all run utopic and btrfs. The busiest server with 1000s of clients and 100's of vhost domains has been up for 6 months without any problems other than initial performance issues because the fs needed to be rebalanced. Once that was done, and once a month, it's been perfectly satisfactory. I also got caught out with sparse sqlite3 databases from Dspam but once they were regularly vacuumed that problem disappeared. I didn't notice that particular problem on the previous ext4/dell-raid system. Personally, my own pair of HP microservers for local backup were renovated from zfs to btrfs 3 months ago and have been working perfectly. Again, particularly so since being rebalanced. The ease of management and flexibility, especially being able to use send/receive to sync them, is just not (so easily) available without btrfs. The key points over LVM is being able to use disks of any size, online transition of raid personalities, file system (not hardware) level checksumming and... subvolumes. I guess my "usage depends on btrfs" is because of it's ease of use and flexibility to cover everything from a single laptop SSD through to various RAID configurations but short of enterprise level openstack-like systems. There the extra stability and performance of LVM is justified in 2015 (maybe 2016) but short of that fairly lofty niche enterprise level of need, this year, I believe btrfs is an overall superior fs solution and a perfect fit for lxc/lxd. Obviously IMHO. _______________________________________________ lxc-users mailing list lxc-users@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-users