Boston Linux & UNIX was originally founded in 1994 as part of The Boston Computer Society. We meet on the third Wednesday of each month at the Massachusetts Institute of Technology, in Building E51.

BLU Discuss list archive


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

[Discuss] NAS: ZFS vs. BtrFS



> From: Discuss [mailto:discuss-bounces+blu=nedharvey.com at blu.org] On
> Behalf Of Tom Metro
> 
> (Is there any other solution outside of a NetApp file
> or BtrFS compare in this area? Maybe with vast quantities of cheap
> storage, the space inefficiency of snapshots is less of a concern.)

Yeah, lots. MS uses volume shadow services. And all the big guys (isilon etc) have some solution in this area. I hear a small number of people using lvm snapshots and AFS.

But I don't really understand your comment about space inefficiency of snapshots - in my mind, nothing could be more efficient, except to not have snapshots (allow data deletion).


> > ...ZFS on linux. Apparently ZFS on linux has been working well now,
> > for at least a couple of years.
> 
> We keep hearing rumors of that, but anyone actually using it?

I haven't personally used it, but I've heard it enough times that I've decided I'm going to do it next time I need something like this. Literally the only reason I use openindiana is to get a ZFS box, and I'd definitely prefer ubuntu or centos.


> How about BtrFS now? I thought I saw some distributions switching to it
> as a primary FS.

It's probably ready. Around 3-ish years ago was the last time I tried it, and it was *almost* ready then. Meaning, I built a server, and tested the ever-loving hell out of it, and it passed all my tests. But then I put it into production and we would occasionally see weird behaviors, and after a very time consuming waste of effort spread over a few months, it was finally tracked down to btrfs. So on that server we scrapped btrfs (and solved the problem), but it was long enough ago that I wouldn't discourage trying again.


> I would *only* consider software RAID. So when I say RAID that's what I
> mean. I lump ZFS's RAID-Z with other software RAID, and don't consider
> it JBOD, as it is not using 100% of the storage for data.

Umm... I have a feeling you already know this, but the way you've phrased above seems like maybe not? You definitely shouldn't lump zfs and btrfs in with "other software raid," because the huge, major reason to use zfs/btrfs software raid instead of hardware raid (besides system compatibility - ability to move disks from one system to another) is the ability to detect & correct data errors.

When the hardware presents only a single device to the OS, if a data error occurs, then the OS has no way to tell the hardware "try reading the other copy, to see if it's good." This means hardware JBOD and software raid are necessary for the OS to do error correction. But many software raids (lvm, for example) don't do checksumming and error correction.


> Now whether the overhead of RAID-Z is low enough that it makes more
> sense to use that over Ext4 on JBOD for a low-reliability backup pool is
> another matter.

This comment doesn't make any sense to me.



BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org