Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Is ZFS a suitable replacement for other Linux filesystems?

clusterhq.com

Post reply on HN
Print view View original

41–50 of 86 posts

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

#41

Post by mrb »

prakashsurya wrote: post #31
FooBarWidget wrote: post #25

Earlier quoted context omitted.

I thought the error checking (scrubbing) only works if you have multiple drives set up in a RAID.

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.

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

#42

Post by Thaxll »

ferrantim wrote: post #4
Thaxll wrote: post #3

No.

Care to elaborate?

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?

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

#43

Post by skorgu »

moe wrote: post #36
ryao wrote: 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.

This is a myth started by someone who did not understand how filesystems work. You are wrong. Don't spread potentially dangerous maladvice on the internet when you have no idea what you're talking about. The official ZFS documentation[1] tells you to use ECC Ram and why. The first google hit for "zfs ecc ram"[2] further elaborates on the risks of using ZFS without ECC memory. [1] https://pthree.org/2013/12/10/zfs-adm…

RAID is not a backup, zfs especially so. Zfs (and RAID) is designed to protect your data from a small, enumerable and specific set of failures, namely the right-there-in-the-acronymn "inexpensive disks".

If your house burns down ZFS will not save your data. If too many disks fail zfs will not save your data. If your disks' unrecoverable read error rate is too high and your array is rebuilding zfs will not save your data.

If your computer is fundamentally broken (which is what a machine with a persistent memory error is) zfs will not save your data.

Take backups.

If you had a 'stuck bit' anywhere in your memory space you'd be way deep into nasal demon unspecified behavior the first time you tried to dereference a pointer that crossed that bit. When your hardware is that broken you can't count on the OS to not stab your dog much less ZFS to do anything sane.

Note that this is just as true for all storage systems. Regular filesystems might corrupt themselves or do other insane things. Hardware RAID or kernel software raid will happily propogate the error. How many bits separate the kernel record for "this disk is totally cool" from "this is a new disk and should be zeroed"?

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

#44

Post by beagle3 »

prakashsurya wrote: post #19
ChrisInEdmonton wrote: post #13

I have heard that ZFS (at least, ZFS on Linux) requires about 1 GB of memory for every 1 TB of storage. Is this an accurate statement? That's certainly a critical flaw for many use cases, though completely irrelevant for many others. If accurate, what's behind this requirement?

No, that's flat out not true. I've seen that metric thrown around when talking about the "dedup" feature of ZFS, but honestly, don't use dedup unless you know what you're doing. It's way to easy for things to go wrong otherwise.

How much memory does ZFS (and/or ZoL) need per 1TB of storage when dedup is off?

Also, bup ("it backs things up!") efficiently dedups across an ssh connection (using bloom filters) Scales are differrent, but it might work for ZFS as well.

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

#45

Post by ryao »

ryao wrote: post #37
po wrote: post #20

I found an old ZFS disk laying around the other day (a few years old.. from when I was playing with zevo community edition ZFS and I had forgotten what I had stored on it) and I was interested in trying https://openzfsonosx.org so I installed it and mounted my disk up. It worked like a charm. I was pretty impressed. I kind of screwed myself over though because I to do a bunch of file cleanup that I was hoping to perh…

This issue was fixed in Illumos a few months ago, although the fix has not made its way to O3X yet: https://github.com/illumos/illumos-gate/commit/4bb7380495217... The workaround is to find a file that was written that is outside of a snapshot and truncate it. `zfs diff` can be used to do that. That allows you to delete an old snapshot.

I ported this fix to ZoL and opened a pull request to get it merged into HEAD for the next release:

https://github.com/zfsonlinux/zfs/pull/2784

O3X merges fixes from ZoL, so it should get this fix soon after it has been merged to ZoL.

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

#46

Post by nisa »

FooBarWidget wrote: post #25
Qantourisc wrote: post #12

Earlier quoted context omitted.

Sure, COW(copy on write), snapshots, error checksum on files, compression, support for SSD's. You just don't have redundancy.

I thought the error checking (scrubbing) only works if you have multiple drives set up in a RAID.

You can also use it on a single drive. You need to set copies=n for a ZFS dataset. If one copy gets corrupted a zpool scrub fixes this problem on a single drive. However HDDs are usually dying fast after signalling bad blocks to the OS so it's not a good strategy to avoid data loss.

Besides that the metadata is still replicated in a single-drive setup. So if you loose data you'll at least know exactly where the error was. This is still a benefit over ext4.

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

#47

Post by snw »

ryanqian wrote: post #28

zfs is a great FS, which add many modern concept such as zpool, and also put volume manager and fs together. storage and fs should be easy as this way. and it's in good quality on Solaris, I miss Solaris.

try one of the Illumos distributions like OmniOS or SmartOS. The legacy of open-solaris is well and alive.

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

#48

Post by po »

ryao wrote: post #45
ryao wrote: post #37

Earlier quoted context omitted.

This issue was fixed in Illumos a few months ago, although the fix has not made its way to O3X yet: https://github.com/illumos/illumos-gate/commit/4bb7380495217... The workaround is to find a file that was written that is outside of a snapshot and truncate it. `zfs diff` can be used to do that. That allows you to delete an old snapshot.

I ported this fix to ZoL and opened a pull request to get it merged into HEAD for the next release: https://github.com/zfsonlinux/zfs/pull/2784 O3X merges fixes from ZoL, so it should get this fix soon after it has been merged to ZoL.

That's great! Thanks for the info.

edit: Didn't realize you meant you just ported it over and submitted the PR just now. Double thanks!

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

#49

Post by otterley »

notacoward wrote: post #6
ryao wrote: 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.

O_DIRECT isn't about durability -- a broken device that falsely reports that data was committed will still be broken when O_DIRECT is used.

O_DIRECT is about bypassing the kernel's buffer cache (and, presumably, zfs's ARC) so that the software can implement its own buffering.

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

#50

Post by ryao »

moe wrote: post #36
ryao wrote: 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.

This is a myth started by someone who did not understand how filesystems work. You are wrong. Don't spread potentially dangerous maladvice on the internet when you have no idea what you're talking about. The official ZFS documentation[1] tells you to use ECC Ram and why. The first google hit for "zfs ecc ram"[2] further elaborates on the risks of using ZFS without ECC memory. [1] https://pthree.org/2013/12/10/zfs-adm…

While it is possible to have an unimportable pool, it is also possible to have ext4 and XFS filesystems that can neither be mounted nor repaired with fsck. When dealing with undefined behavior caused by bit flips, virtually any failure is possible, especially when you consider bit flips to kernel data structures. No software can save you from bit flips and if they are your concern (as they should be), then you should refuse to use computers that lack ECC RAM.

As for the articles that you link, they are correct to say that you want to use ECC RAM. However, there is nothing specific to ZFS that makes it require ECC any more than any other filesystem. It should also be noted that I wrote the official documentation on this subject. It can be found at the Open ZFS wiki, rather than the pages you linked:

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

Post reply on HN