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

81–86 of 86 posts

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

#81

Post by DuskStar »

tehmaco wrote: post #52
beagle3 wrote: post #44

Earlier quoted context omitted.

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.

The recommendations I've read say you need 1GB RAM for system use (assuming a dedicated file server), and then as much RAM (ideally ECC RAM) as you want to give it for caching data. If you're short on RAM (sub 4GB), you might need to change some of the default settings to avoid problems, but RAM's fairly cheap nowadays, so unless you've got an old machine, it's not likely to be a problem :)

I'd point out that cheap ram is about $10/GB right now, and a cheap HDD is $30/TB. So if you need an extra GB of ram for each TB of storage, you're increasing storage costs by a third.

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

#82

Post by ryao »

erikb wrote: post #79

Not being an expert in this kind of area, I would really like to read a short summary. Is there one and I just have missed it, somewhere in the article? I didn't see a headline like summary or conclusions.

Nearly all software works on ZoL. A small number of applications will likely need configuration of the application(s) to turn off AIO (until the next release), configuration of the application(s) to turn off DirectIO, or setting acltype=posix on the dataset to provide POSIX ACLs.

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

#83

Post by ryao »

moe wrote: post #80
ryao wrote: post #50

Earlier quoted context omitted.

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…

I apologize. I was sure to be dealing with a troll and was sloppy with my sources (i.e. I was sure to have once read it in the official docs, but here I just linked the first official looking google hit that was not the solaris docs). there is nothing specific to ZFS that makes it require ECC any more than any other filesystem This statement still troubles me. I was under the assumption that ZFS scrubbing may indeed…

It is easy to get confused and it could happen to anyone.

That said, the only thing in the code remotely similar to "compound corruption" is logic for preventing such a scenario, which has the following comment:

			/*
			 * Don't rewrite known good children.
			 * Not only is it unnecessary, it could
			 * actually be harmful: if the system lost
			 * power while rewriting the only good copy,
			 * there would be no good copies left!
			 */
https://github.com/zfsonlinux/zfs/blob/master/module/zfs/vde...

That touches more than obvious at a glance because the mirror code is used for processing both mirrors and ditto blocks.

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

#84

Post by po »

valarauca1 wrote: post #40
po wrote: post #30

Earlier quoted context omitted.

Are you referencing this thread? https://groups.google.com/forum/#!topic/zfs-macos/qguq6LCf1Q... I've heard this but I haven't actually confirmed anywhere official that ZFS will try to scrub your data due to a parity flip in ram values. Where in the manuals do they talk about it? (I'm actually curious about if it's just a rumor or if it's acknowledged)

Referencing this https://pthree.org/2013/12/10/zfs-administration-appendix-c-... http://louwrentius.com/please-use-zfs-with-ecc-memory.html

Even after reading that, I'm still not convinced it's any worse than something like btrfs+non-ECC memory. The most convincing part is the 'there are less tools' to recover from corruption angle.

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

#85

Post by anon1385 »

ryao wrote: post #83
moe wrote: post #80

Earlier quoted context omitted.

I apologize. I was sure to be dealing with a troll and was sloppy with my sources (i.e. I was sure to have once read it in the official docs, but here I just linked the first official looking google hit that was not the solaris docs). there is nothing specific to ZFS that makes it require ECC any more than any other filesystem This statement still troubles me. I was under the assumption that ZFS scrubbing may indeed…

It is easy to get confused and it could happen to anyone. That said, the only thing in the code remotely similar to "compound corruption" is logic for preventing such a scenario, which has the following comment: /* * Don't rewrite known good children. * Not only is it unnecessary, it could * actually be harmful: if the system lost * power while rewriting the only good copy, * there would be no good copies left! */ ht…

Sorry for the very late reply that you probably won't see.

I'm not familiar with ZFS at all, so I don't know what the terminology 'ditto blocks' and 'mirrors' mean, so there's a good chance I'm not talking sense here at all.

The main argument for ZFS on non-ECC using systems being worse than other less sophisticated file systems seems to be that just reading a file (or during periodic 'scrubbing') while you have bad ram can cause good files to be corrupted when ZFS notices checksum errors and tries to correct them. (There are other arguments about not being able to mount pools due to bad ram, but that seems no different to any other FS).

People seem to be quite insistent that this is possible, and at first glance the code you linked above doesn't seem to be relevant since it refers to 'known good' data, but the problem scenario is when data has (erroneously) been determined to be bad due to faulty ram. Will ZFS overwrite good data in that situation in an attempt to correct what it sees as a disk error?

A few links where people are making this claim:

https://forums.freenas.org/index.php?threads/ecc-vs-non-ecc-...

https://forums.freenas.org/index.php?threads/ecc-vs-non-ecc-...

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

#86

Post by nske »

XorNot wrote: post #68
nske wrote: post #51

Earlier quoted context omitted.

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.

Thanks, you mean LVM2/ZFS/BTRFS based snapshots right? I've seen that mentioned but I was thinking that eventually, with system updates, the snapshots will end up having less and less common blocks with their original source, so I would have to frequently recreate new snapshots from a more similar source and then copy the unique data on top of them again to raise the hit rate -but that sounds a pretty inconvenient thing to do.
Post reply on HN