Re: [gentoo-user] Re: File system testing

[J. Roeleveld]

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