Live data from Hacker News

Is ZFS a suitable replacement for other Linux filesystems?

clusterhq.com

61–70 of 86 posts

Re: Is ZFS a suitable replacement for other Linux filesystems?

#61
post #57
post #8

Earlier quoted context omitted.

This is a myth started by someone who did not understand how filesystems work. Not having ECC memory is no more of a handicap for ZFS than it is for any other filesystem.

A person at the FreeNAS forums wrote a forum post explaining his mistaken believed that ZFS is somehow more prone to catastrophic data loss when bit flips occurred than other filesystems: https://forums.freenas.org/index.php?threads/ecc-vs-non-ecc-... The reality is that the worst case consequences for a bit flip is the complete loss of all data, regardless of the filesystem used. While the automated repair routined…

Indeed. I can reiterate this point. I have helped a few administrators, who initially were compiling ZFS on Linux from source, then decided to switch to the Launchpad PPA repository, and "upgrade" their userspace tools. Next thing I know, they are asking me if there is anything they can do to recover their pool. After a bit of research, and a little cleaning up, I am able to get their pool back online, with zero data loss.

I have had a VERY hard time finding a situation where there was corrupted data in ZFS, and where there are ZFS pools that absolutely will not import back into full operation.

In other words, it is pretty difficult to "accidentally" corrupt a ZFS pool to the point of not being able to recover your data.

ECC RAM greatly minimizes the potential for a corrupted file in ZFS, but ECC RAM also greatly minimizes the potential for a corrupted file in ext4 or XFS.

So long story short, I have experienced the same thing as ryao, and come to the same conclusions.

Re: Is ZFS a suitable replacement for other Linux filesystems?

#62
post #8

Earlier quoted context omitted.

This is a myth started by someone who did not understand how filesystems work. Not having ECC memory is no more of a handicap for ZFS than it is for any other filesystem.

Care to elaborate? ZFS warned me of that while I reading its installation guide. Which is why I never installed it.

If you're doing RAID, you should have ECC. All hardware RAID controllers have ECC cache, and if you're doing software RAID, you should have ECC system RAM. But this is just common sense, I guess, since it's useless to write data to redundant storage if it's already been bit-flipped in RAM.

Re: Is ZFS a suitable replacement for other Linux filesystems?

#63
post #2

I wrote the above article. I will try to answer any questions that I see here.

Who offers production Level support? Certification? No one AFAICS. I wonder why you didn't mention that.

It was not the purpose of the blog post. Anyway, you mentioned a couple of different things here. First, there are a few companies that offer production level support. SoftNAS is one. For full disclosure, my 2014 tax return will include consulting fees earned from fixing bugs for SoftNAS. It is in use at various large companies, including Netflix and Boeing:

http://www.softnas.com/

Another is PogoStor, which advertises that the hardware that they sell has been certified by Nexenta for use with ZFS:

http://www.pogostorage.com/products/nexenta/overview/whycert...

They also have their own Linux distribution based on ZoL, for which I assume that they offer commercial support:

http://www.pogostorage.com/products/pogostor/pogostor-overvi...

As for certification, it is not clear if you mean hardware certification or system administrator certification. I am not aware of any filesystems that have system administrator certifications. As for hardware certifications, ZFS is designed for use with commodity hardware. It probably does not make sense to try to certify it for the full range of hardware it supports (although a subset is certified by Nexenta). Specific hardware guidelines are available on the official Open ZFS wiki:

http://open-zfs.org/wiki/Hardware

Re: Is ZFS a suitable replacement for other Linux filesystems?

#64
post #2

I wrote the above article. I will try to answer any questions that I see here.

Nice article. I think you understate the importance of O_DIRECT, since it's the only way many kinds of software can work around the utter lameness of Linux local filesystems' durability semantics, but other than that I think it's extremely informative and useful.

As another commenter noted it's not a complete durability solution. However it is useful in a number of places - and not just to do with durability.

AIO is also very extensively used, and bmap is pretty important.

It's really important when writing comparison pages like this to not play down the weaknesses of the thing you're trying to sell - it comes across badly. O_DIRECT, AIO and to a lesser extent bmap are feature that are required of a general purpose linux filesystem. I'm sure you'll have them all working in ZoL soon enough, but please don't try to pretend they aren't important.

I'm also not sure why you have NFS in there - network filesystems are not local filesystems, and aren't generally going to have identical feature-sets. It feels a bit like you just stuck NFS in there so that there'd at least be something with more missing features. The same could kind of be said of JFS - I haven't heard of anyone using JFS on linux in a serious way in a very long time.

Re: Is ZFS a suitable replacement for other Linux filesystems?

#65
post #41

Earlier quoted context omitted.

Error detection can always be used, but error correction may or may not be available (it depends on the type of block). Metadata blocks are redundant even on a single drive pool; so if you just have a partial failure (e.g. overwrite a metadata block) it might be able to correct the block using another redundant copy on the same drive. Data blocks will require a redundant pool configuration, though, as these are not s…

Actually you can correct data blocks, on a single-drive ZFS pool, if you set the attribute copies=2 (ditto blocks): https://blogs.oracle.com/relling/entry/zfs_copies_and_data_p... Obviously this redundancy feature makes you use twice the disk space you would normally use.

yup, that's why I added "by default". a user won't get that functionality without explicitly asking for it.

Re: Is ZFS a suitable replacement for other Linux filesystems?

#66
post #42

Earlier quoted context omitted.

The article is missing many things that make a FS suitable for production, it's listing every features but lack the reliability / cons / waknesses ect... ZFS is nowhere near production ready for Linux. I know XFS and ext4 under heavy load with different scenarios, could you tell the same for ZoL?

Yes, I can. I am a system administrator who also knows a great deal about storage, and manages a good chuck of the storage servers at my employment. We use ZFS for our backup servers, both onsite, and offsite, and we use them for a couple generic storage servers as well, one of which is constantly under heavy stress, all the time. That server is http://mirrors.xmission.com . I am personally using it on my workstation…

is lack of trim support not a substantial issue? (for those using SSDs)

Re: Is ZFS a suitable replacement for other Linux filesystems?

#67
post #66

Earlier quoted context omitted.

Yes, I can. I am a system administrator who also knows a great deal about storage, and manages a good chuck of the storage servers at my employment. We use ZFS for our backup servers, both onsite, and offsite, and we use them for a couple generic storage servers as well, one of which is constantly under heavy stress, all the time. That server is http://mirrors.xmission.com . I am personally using it on my workstation…

is lack of trim support not a substantial issue? (for those using SSDs)

It can cause performance degradation when all the banks in the SSD have been written to, and a new bank needs to be re-written. TRIM allows cleaning the bank when it is no longer needed, and hopefully, before it needs to be written again. As such, the new rewrite will be native speed, and not bottle-necked

Re: Is ZFS a suitable replacement for other Linux filesystems?

#68
post #51

Earlier quoted context omitted.

No problem. It's really a shame to have such a high bar for using dedup. It either fits a given workload extremely well, or can be extremely detrimental. There's been talk in the developer community about ways to address the usability of dedup, but so far nothing has gone further than small prototypes.

I think for many or most use-cases, it would make more sense to have "off-line" deduplication (like, I believe, BTRFS does), as you can free-up space on-demand, when you judge it would yield you the most benefit and the system is the least busy. I'm not sure how much benefit compared to the "real time" deduplication this approach can provide however, as the mapping table would still need to exist in memory, but I thi…

Cloned snapshots carcass good way to dediplicate similar FS trees and have no RAM overhead. Its functionally the same as hardlinking.

Re: Is ZFS a suitable replacement for other Linux filesystems?

#69
post #63

Earlier quoted context omitted.

Who offers production Level support? Certification? No one AFAICS. I wonder why you didn't mention that.

It was not the purpose of the blog post. Anyway, you mentioned a couple of different things here. First, there are a few companies that offer production level support. SoftNAS is one. For full disclosure, my 2014 tax return will include consulting fees earned from fixing bugs for SoftNAS. It is in use at various large companies, including Netflix and Boeing: http://www.softnas.com/ Another is PogoStor, which advertis…

ixsystems also provides support for ZFS on FreeNAS, which is based on FreeBSD.
Post reply on HN