On Thursday, September 18, 2014 05:48:58 AM Rich Freeman wrote: > The HTML...it hurts my eyes... :)
Apologies. > > My current understanding is: > > > > - ZFS is production ready, but due to licensing issues, not included in > > the > > kernel > > > > - BTRFS is included, but not yet production ready with all planned > > features > > Your understanding of their maturity is fairly accurate. They also > aren't 100% moving in the same direction - btrfs aims more to be a > general-purpose filesystem replacement especially for smaller systems, > and zfs is more focused on the enterprise, so it lacks features like > raid reshaping (who needs to add 1 disk to a raid5 when you can just > add 5 more disks to your 30 disk storage system). Thank you for this info. I wasn't aware of this difference in 'design'. Sounds like ZFS will be more suited for me then. > I think btrfs has a bit more hope of being an ext4 replacement some > day for both this reason and the licensing issue. That in no way > detracts from the usefulness of zfs, especially for larger deployments > where the few areas where btrfs is more flexible would probably be > looked at as gimmicks (kind of like being able to build your whole OS > from source :) ). Next time I am rebuilding the desktops, I will likely switch them to BTRFS. Sounds like BTRFS will be more suited there. > > For me, Raid6-like functionality is an absolute requirement and latest I > > know is that that isn't implemented in BTRFS yet. Does anyone know when > > that will be implemented and reliable? Eg. what time-frame are we talking > > about? > I suspect we're talking months before it is really implemented, and > much longer before it is reliable. Right now btrfs can write raid6, > but it can't really read it. That is, it operates just fine until you > actually lose a disk containing something other than parity, and then > it loses access to the data. This code is only in the kernel for > development purposes and nobody advocates using it for production. > Most of the code in btrfs which is reliable has been around for years, > like raid1 support, and obviously it will be years until the raid5/6 > code reaches that point. I am using btrfs mainly because once that > day comes it will be much easier to migrate to it from btrfs raid1 > than from zfs (which has no mechanism for migrating raid levels > in-place (that is, within an existing vdev) - you would need to add > new drives to the pool, migrate the data, and remove the old drives > from the pool, which is nice if you have a big stack of drives and > spare sata ports lying around like you would in a SAN). Exactly, although I prefer not to change the filesystem on a live system anytime soon. When it comes to redoing the filesystem like that, restoring from backups will be the fastest solution. -- Joost
