48 ms·

Summary of ZFS on Linux for Debian

141 points by ferrantim 12y ago

_delirium 12y ago
> Debian maintainers vote to ship ZFSonLinux in Debian I don't believe that's what the linked post is saying. I may be missing additional context that's posted elsewhere, but at least what I read in this thread is: 1) the Debian ftpmasters rejected the binary ZFS module upload; and 2) the Debian ZFS-on-Linux team met at Debconf 14 and agreed on this summary/response, arguing why it should be accepted. But has that response itself been accepted? Where is the mentioned vote? The only other post I see in the linked thread is from Lucas Nussbaum (Debian project leader), which sounds inconclusive, I think that adding an actual question to our legal counsel would help focus their work. ... I'll wait for comments or ACK from ftpmasters before forwarding your mail to SFLC.
- ryao 12y ago
  You are correct. There is no sign of a vote. That inaccuracy aside, the outline of the general understanding of the licensing situation is a step in the right direction. The email itself suggests that there was tentative agreement over this at DebConf 14, which is promising.
  - ferrantim 12y ago
    Sorry for introducing that inaccuracy when I posted the title. I mistakenly interpreted "As agreed at DebConf 14, Debian ZFS on Linux Maintainers have concluded..." as the equivalent of a vote.
  - _delirium 12y ago
    My read was that there was agreement at DebConf 14 among the ZFS-on-Linux maintainers specifically, not necessarily that they'd gotten buy-in from the wider Debian community. It's somewhat unclear though.
- zurn 12y ago
  Also, their legal reasoning (based on EXPORT_SYMBOL_GPL) is one that has been repeatedly contested by various people including some Linux authors.
  - _delirium 12y ago
    People do dispute that reasoning, but I think this statement is correct that if you don't accept that reasoning, Debian also needs to stop shipping proprietary drivers [1] that depend on the same rationale (Debian currently considers such drivers non-free, but not GPL-violating). [1] e.g. https://packages.debian.org/sid/nvidia-driver https://packages.debian.org/sid/nvidia-driver
ryao 12y ago
Installing / on ZFS is fairly easy on most major Linux distributions, but Debian has been the main exception due to its initramfs generator lacking ZFS support. I am cautiously optimistic that will change. If not, then this issue should go away when I publish ZFS support patches for syslinux later this year. syslinux is capable of generating initramfs archives on the fly, so adding ZFS support to it should largely eliminate the need for distribution-specific initramfs generators.
- LaikaF 12y ago
  I am not a particularly good Linux user ( I have to look up most commands/ where things are) and I had no problem getting ZFS set up on Debian. I'm worried now that you say this, because I feel I may have messed something up.
  - StavrosK 12y ago
    He's talking about the root partition being on ZFS, not just setting up an array.
    - RexRollman 12y ago
      Don't most people just use a /boot partition anyway?
  - ryao 12y ago
    If it works for you, then there is no need to worry. I only said that because there are others who had difficulty setting this up.
  - javanix 12y ago
    Do you boot from your ZFS partition? The initramfs limitation would only come into play in that situation, I believe.
    - LaikaF 12y ago
      Naa, I'm good then. Or at least in that regard.
acd 12y ago
ZFS on Linux is very good!
- aruggirello 12y ago
  But is it, performance-wise? How will ZFS compare to btrfs?
  - pizza234 12y ago
    At this point in time, they still can't be compared, because btrfs is still not [considered] production-ready, and subject to significant changes (also performance-related). This is especially important because on use cases where performance differences are significant, that is, not on general desktop usage, the maturity of the FS is funamental, and btrfs is discouraged right now.
    - derefr 12y ago
      There are many situations where performance is important, and durability is... not. For example, ephemeral CoreOS cloud instances running Docker containers: they use lots of copy-on-write layers, but they don't actually need to persist any state across reboots (the layers may as well be stored in volatile memory.) Btrfs is perfectly "production-ready" for this particular use-case, so a [current] performance comparison would be pretty useful.
      - ryao 12y ago
        I am working on ZFS support for CoreOS. A snapshot of my WIP proof of concept was posted by my employer yesterday: https://github.com/ClusterHQ/flocker/blob/zfs-on-coreos-tutorial-667/docs/experimental/zfs-on-coreos.rst https://github.com/ClusterHQ/flocker/blob/zfs-on-coreos-tuto... CoreOS uses btrfs as its rootfs. I imagine that the CoreOS developers managed to avoid issues like ENOSPC by virtue of not writing to their rootfs very much. I did not have that luxury since I compiled a Gentoo GNU userland on top of it during the course of development. I encountered numerous ENOSPC errors on btrfs when developing the ZFS port to CoreOS and even hit ENOSPC errors when trying to correct the btrfs ENOSPC errors with `btrfs balance /`. I would not consider btrfs ready for production use, but your mileage will vary.
fiatmoney 12y ago
I use ZFS on Linux for my file server. One of the nicest things about it is that the caching algos actually work - they're resilient to scans, so I can, for instance, have an intensively used database file that remains in RAM, even while & after doing a linear scan over a large number of files (eg during rsync). With the standard Linux page replacement algos, linear reads will flush the stuff you're actually using out of the page cache. The fact that the caching algos are so good at keeping things in memory is why everyone gets hung up on using ECC RAM with it.
- mrb 12y ago
  This is not the reason why people recommend ECC. ZFS is so good at detecting corruption (CKSUM errors) that when it happens it is hard to tell what caused it: faulty RAM corrupting data before being written to disk or after being read from disk, or data corrupted on disk? ECC simply helps reduce a good chunk of corruption errors caused by faulty RAM. That said, in my experience there are a few tell-tale signs that RAM is the issue: when you see CKSUM errors poping up infrequently, and not being attributed to consistently the same drive(s).
  - byuu 12y ago
    I haven't had any issues so far using four drives mirrored on ZFS, but the ECC issue certainly worries me. I'd love to run ECC RAM, but I'd have to buy a much more expensive processor, a much more expensive mainboard, and all of my RAM would have to be swapped for moderately more expensive replacements. And DDR3+ is not cheap. I'm curious though, if ECC consists of a ninth parity bit, is there any reason why a memory controller can't be designed that would, worst case, use every other (identical) stick just to get parity bit(s), as a BIOS configurable option? Sure it'd halve your RAM, or you'd pay a lot more in RAM costs, but not having to buy Xeon processors and mainboards, and getting to reuse your existing RAM, would be worth buying an extra stick of RAM in my opinion. It seems as processes keep getting smaller, and RAM sizes keep getting larger, that the effects of cosmic radiation are just going to keep getting worse. If we can't get desktop CPUs and mainboards to just switch to ECC, surely this would at least be a better-than-nothing option.
aidenn0 12y ago
It's interesting that the Debian people feel that ZoL is not a derivative work. I remember a thread where RMS claimed to Bruno Haible that clisp was a derivative work of readline, since it had optional readline support. I always thought that position was untenable, but since Haible was open to licensing clisp under GPL anyway, there wasn't a whole lot of pushback.
- ryao 12y ago
  In that case, readline was not a loadable module. A comparison that does use loadable modules is the FSF's GCC project. The FSF resisted implementing support for loadable modules in GCC for a long time under the belief that it would allow the use of GPL-incompatible modules. It was not until LLVM made it a moot point because GCC itself could be replaced entirely non-copyleft code that GCC gained support for this. Linux kernel module support analogously permits loading modules that are under GPL-incompatible licenses. Note that I am not associated with the Debian project and therefore I was not involved in the discussion referenced here.
  - mikepurvis 12y ago
    Another one I've been wondering about recently is the inverse— loading at runtime a GPL module into an otherwise BSD codebase. ROS (robot operating system) runs into this with nodelets, which are shared objects that are loaded into a nodelet manager. Is it a GPL violation to supply a launchfile which specs the loading of BSD and GPL nodelets into a single running process?
    - yebyen 12y ago
      BSD and GPL are actually compatible and can be distributed together. It's my understanding that the advertising clause is the bit that makes them incompatible, and that regular BSD and GPL code can be bundled and distributed together. What else I got from the OP thread is that if you do this (lets just assume the two licenses are incompatible) then you are not the violator, since you haven't distributed these as one binary package, but the users might be (only if they go on to redistribute the pre-built confabulation of binaries/processes as one package, or even just in uploading them together to, say, a hosting provider.)
WestCoastJustin 12y ago
If you are looking at playing around with ZFS on Linux, be sure to check out Aaron Toponce's awesome series of articles, entitled "Install ZFS on Debian GNU/Linux" [1]. I have also done a two part screencast about using ZFS on Linux [2], part two will be released later today. [1] https://pthree.org/2012/04/17/install-zfs-on-debian-gnulinux/ https://pthree.org/2012/04/17/install-zfs-on-debian-gnulinux... [2] https://sysadmincasts.com/episodes/35-zfs-on-linux-part-1-of-2 https://sysadmincasts.com/episodes/35-zfs-on-linux-part-1-of...
jeffdavis 12y ago
Why doesn't Oracle just change ZFS to dual-license GPL/CDDL, and scrap btrfs? My experiences with ZFS have been quite good, and with btrfs quite bad.
- orkoden 12y ago
  Because Oracle wants you to buy Solaris if you do serious business.
  - acdha 12y ago
    Oracle wants you to buy support contracts. They'd be perfectly happy to have those be for Oracle Linux rather than Solaris since they don't have to do all of the engineering that way.
  - fafner 12y ago
    or Oracle Linux. I don't know if they are shipping ZFS support with it yet. But they are already shipping dtrace with it which suffers from the same license issues.
    - ryao 12y ago
      I asked the Oracle representative at LinuxCon North America 2014 this question and explicitly mentioned that it was already shipping CDDL kernel code because of DTrace. He could not answer this question, but claimed that he would get back to me. So far, I have not heard back.
      - fafner 12y ago
        They are currently using a trick trying to circumvent the EXPORT_SYMBOL_GPL issue. But it is highly dubious whether this is legally sound: ktime_t dtrace_gethrtime(void) { return ktime_get(); } EXPORT_SYMBOL(dtrace_gethrtime); http://mjg59.dreamwidth.org/31357.html http://mjg59.dreamwidth.org/31357.html In the end I assume this is intentional to keep the license issue of dtrace and ZFS in a dubious state. Thus preventing other distributions from shipping it. Meanwhile Oracle can ship it because they aren't going to sue themselves and the kernel folks seem rather uninterested in lawsuits as well (and even if they did then Oracle could drag it out forever considering that the company seems to have more lawyers than developers).
byuu 12y ago
So it sounds like they are okay with binary kernel modules, just not built-in to the base kernel. FreeBSD manages to do ZFS as a kernel module (plus another module for Open Solaris abstractions) quite successfully. Although it has somewhat of an ugly ZFS-on-root shim loader for booting from a ZFS partition, it does certainly get the job done. Here's hoping Debian can develop something similar so that users can create and boot from a ZFS partition during their installer. > CCDL is an Open Source License that is DFSG compliant I don't mean to nitpick, but if you're going to discuss the legalities of a license, at least spell it correctly. It's not CCDL, it's CDDL, or Common Development and Distribution License.
Thaxll 12y ago
I stopped using ZFS when I learn that using non ECC memory was dangerous and could corrupt sane data.
- ryao 12y ago
  The filesystem that you use has nothing to do with the opportunity for bit flips in non-ECC RAM to cause issues. If you are concerned about the effect of bit flips in non-ECC memory on filesystems, then the solution is to use only systems that have ECC memory. There is no other way to deal with that problem.
- ChuckMcM 12y ago
  I'm confused by this statement, using 'non ECC' memory is dangerous and does corrupt otherwise sane data. Using or not using ZFS doesn't change this danger.
  - Thaxll 12y ago
    Other FS won't try to correct sane data on HDD but corrupted when loaded in memory.
    - ryao 12y ago
      You are describing what undefined behavior might manifest in response to a bit flip. It is undefined for the reason that anything can go wrong, although I have trouble seeing how the particular scenario you describe here would cause a problem. If the checksum verification fails on a read because of a bit flip in the data, ZFS will just load another copy. That being said, it is not a good idea to use hardware that lacks ECC RAM. No filesystem developer will claim that their kernel driver can operate properly without ECC RAM because it is not possible. Email the linux-fsdevel mailing list if you want confirmation.
    - XorNot 12y ago
      ZFS does not do this. Your assumptions about what other FSs do is inaccurate. Consider: you load data from ext4 into RAM, it gets corrupted. You change some bytes, then save it. Corrupted data is then written to the disk. Could be anything inside the allocation unit size, which is 4K generally - not insubstantial. ZFS's worst case behavior is exactly the same: it can't protect you from corruption in RAM after checksum validation if you then ask it to save that data to disk. There is no difference: if you do not have ECC RAM, you are vulnerable to bitflips corrupting your data - and they will have been. ZFS won't corrupt data which gets altered in memory due to a bitflip but is only ever read. It can't - because in-memory bitflips can't be detected. Even if at some point during checksum validation there was a mismatch, the restore is done from checksum protected parity/mirror image data. And if the restore block were corrupted, the checksum won't match and ZFS will rebuild the block correctly next time. If you do not have ECC RAM, every filesystem will potentially corrupt your data. ZFS is more resilient then pretty much all of them even in this case.

141 points by ferrantim 12y ago

> Debian maintainers vote to ship ZFSonLinux in Debian I don't believe that's what the linked post is saying. I may be missing additional context that's posted elsewhere, but at least what I read in this thread is: 1) the Debian ftpmasters rejected the binary ZFS module upload; and 2) the Debian ZFS-on-Linux team met at Debconf 14 and agreed on this summary/response, arguing why it should be accepted. But has that response itself been accepted? Where is the mentioned vote? The only other post I see in the linked thread is from Lucas Nussbaum (Debian project leader), which sounds inconclusive, I think that adding an actual question to our legal counsel would help focus their work. ... I'll wait for comments or ACK from ftpmasters before forwarding your mail to SFLC.

ryao 12y ago
You are correct. There is no sign of a vote. That inaccuracy aside, the outline of the general understanding of the licensing situation is a step in the right direction. The email itself suggests that there was tentative agreement over this at DebConf 14, which is promising.
- ferrantim 12y ago
  Sorry for introducing that inaccuracy when I posted the title. I mistakenly interpreted "As agreed at DebConf 14, Debian ZFS on Linux Maintainers have concluded..." as the equivalent of a vote.
- _delirium 12y ago
  My read was that there was agreement at DebConf 14 among the ZFS-on-Linux maintainers specifically, not necessarily that they'd gotten buy-in from the wider Debian community. It's somewhat unclear though.
zurn 12y ago
Also, their legal reasoning (based on EXPORT_SYMBOL_GPL) is one that has been repeatedly contested by various people including some Linux authors.
- _delirium 12y ago
  People do dispute that reasoning, but I think this statement is correct that if you don't accept that reasoning, Debian also needs to stop shipping proprietary drivers [1] that depend on the same rationale (Debian currently considers such drivers non-free, but not GPL-violating). [1] e.g. https://packages.debian.org/sid/nvidia-driver https://packages.debian.org/sid/nvidia-driver

ryao 12y ago

Installing / on ZFS is fairly easy on most major Linux distributions, but Debian has been the main exception due to its initramfs generator lacking ZFS support. I am cautiously optimistic that will change. If not, then this issue should go away when I publish ZFS support patches for syslinux later this year. syslinux is capable of generating initramfs archives on the fly, so adding ZFS support to it should largely eliminate the need for distribution-specific initramfs generators.

LaikaF 12y ago
I am not a particularly good Linux user ( I have to look up most commands/ where things are) and I had no problem getting ZFS set up on Debian. I'm worried now that you say this, because I feel I may have messed something up.
- StavrosK 12y ago
  He's talking about the root partition being on ZFS, not just setting up an array.
  - RexRollman 12y ago
    Don't most people just use a /boot partition anyway?
- ryao 12y ago
  If it works for you, then there is no need to worry. I only said that because there are others who had difficulty setting this up.
- javanix 12y ago
  Do you boot from your ZFS partition? The initramfs limitation would only come into play in that situation, I believe.
  - LaikaF 12y ago
    Naa, I'm good then. Or at least in that regard.

acd 12y ago

ZFS on Linux is very good!

aruggirello 12y ago
But is it, performance-wise? How will ZFS compare to btrfs?
- pizza234 12y ago
  At this point in time, they still can't be compared, because btrfs is still not [considered] production-ready, and subject to significant changes (also performance-related). This is especially important because on use cases where performance differences are significant, that is, not on general desktop usage, the maturity of the FS is funamental, and btrfs is discouraged right now.
  - derefr 12y ago
    There are many situations where performance is important, and durability is... not. For example, ephemeral CoreOS cloud instances running Docker containers: they use lots of copy-on-write layers, but they don't actually need to persist any state across reboots (the layers may as well be stored in volatile memory.) Btrfs is perfectly "production-ready" for this particular use-case, so a [current] performance comparison would be pretty useful.
    - ryao 12y ago
      I am working on ZFS support for CoreOS. A snapshot of my WIP proof of concept was posted by my employer yesterday: https://github.com/ClusterHQ/flocker/blob/zfs-on-coreos-tutorial-667/docs/experimental/zfs-on-coreos.rst https://github.com/ClusterHQ/flocker/blob/zfs-on-coreos-tuto... CoreOS uses btrfs as its rootfs. I imagine that the CoreOS developers managed to avoid issues like ENOSPC by virtue of not writing to their rootfs very much. I did not have that luxury since I compiled a Gentoo GNU userland on top of it during the course of development. I encountered numerous ENOSPC errors on btrfs when developing the ZFS port to CoreOS and even hit ENOSPC errors when trying to correct the btrfs ENOSPC errors with `btrfs balance /`. I would not consider btrfs ready for production use, but your mileage will vary.

fiatmoney 12y ago

I use ZFS on Linux for my file server. One of the nicest things about it is that the caching algos actually work - they're resilient to scans, so I can, for instance, have an intensively used database file that remains in RAM, even while & after doing a linear scan over a large number of files (eg during rsync). With the standard Linux page replacement algos, linear reads will flush the stuff you're actually using out of the page cache. The fact that the caching algos are so good at keeping things in memory is why everyone gets hung up on using ECC RAM with it.

mrb 12y ago
This is not the reason why people recommend ECC. ZFS is so good at detecting corruption (CKSUM errors) that when it happens it is hard to tell what caused it: faulty RAM corrupting data before being written to disk or after being read from disk, or data corrupted on disk? ECC simply helps reduce a good chunk of corruption errors caused by faulty RAM. That said, in my experience there are a few tell-tale signs that RAM is the issue: when you see CKSUM errors poping up infrequently, and not being attributed to consistently the same drive(s).
- byuu 12y ago
  I haven't had any issues so far using four drives mirrored on ZFS, but the ECC issue certainly worries me. I'd love to run ECC RAM, but I'd have to buy a much more expensive processor, a much more expensive mainboard, and all of my RAM would have to be swapped for moderately more expensive replacements. And DDR3+ is not cheap. I'm curious though, if ECC consists of a ninth parity bit, is there any reason why a memory controller can't be designed that would, worst case, use every other (identical) stick just to get parity bit(s), as a BIOS configurable option? Sure it'd halve your RAM, or you'd pay a lot more in RAM costs, but not having to buy Xeon processors and mainboards, and getting to reuse your existing RAM, would be worth buying an extra stick of RAM in my opinion. It seems as processes keep getting smaller, and RAM sizes keep getting larger, that the effects of cosmic radiation are just going to keep getting worse. If we can't get desktop CPUs and mainboards to just switch to ECC, surely this would at least be a better-than-nothing option.

aidenn0 12y ago

It's interesting that the Debian people feel that ZoL is not a derivative work. I remember a thread where RMS claimed to Bruno Haible that clisp was a derivative work of readline, since it had optional readline support. I always thought that position was untenable, but since Haible was open to licensing clisp under GPL anyway, there wasn't a whole lot of pushback.

ryao 12y ago
In that case, readline was not a loadable module. A comparison that does use loadable modules is the FSF's GCC project. The FSF resisted implementing support for loadable modules in GCC for a long time under the belief that it would allow the use of GPL-incompatible modules. It was not until LLVM made it a moot point because GCC itself could be replaced entirely non-copyleft code that GCC gained support for this. Linux kernel module support analogously permits loading modules that are under GPL-incompatible licenses. Note that I am not associated with the Debian project and therefore I was not involved in the discussion referenced here.
- mikepurvis 12y ago
  Another one I've been wondering about recently is the inverse— loading at runtime a GPL module into an otherwise BSD codebase. ROS (robot operating system) runs into this with nodelets, which are shared objects that are loaded into a nodelet manager. Is it a GPL violation to supply a launchfile which specs the loading of BSD and GPL nodelets into a single running process?
  - yebyen 12y ago
    BSD and GPL are actually compatible and can be distributed together. It's my understanding that the advertising clause is the bit that makes them incompatible, and that regular BSD and GPL code can be bundled and distributed together. What else I got from the OP thread is that if you do this (lets just assume the two licenses are incompatible) then you are not the violator, since you haven't distributed these as one binary package, but the users might be (only if they go on to redistribute the pre-built confabulation of binaries/processes as one package, or even just in uploading them together to, say, a hosting provider.)

WestCoastJustin 12y ago

If you are looking at playing around with ZFS on Linux, be sure to check out Aaron Toponce's awesome series of articles, entitled "Install ZFS on Debian GNU/Linux" [1]. I have also done a two part screencast about using ZFS on Linux [2], part two will be released later today. [1] https://pthree.org/2012/04/17/install-zfs-on-debian-gnulinux/ https://pthree.org/2012/04/17/install-zfs-on-debian-gnulinux... [2] https://sysadmincasts.com/episodes/35-zfs-on-linux-part-1-of-2 https://sysadmincasts.com/episodes/35-zfs-on-linux-part-1-of...

jeffdavis 12y ago

Why doesn't Oracle just change ZFS to dual-license GPL/CDDL, and scrap btrfs? My experiences with ZFS have been quite good, and with btrfs quite bad.

orkoden 12y ago
Because Oracle wants you to buy Solaris if you do serious business.
- acdha 12y ago
  Oracle wants you to buy support contracts. They'd be perfectly happy to have those be for Oracle Linux rather than Solaris since they don't have to do all of the engineering that way.
- fafner 12y ago
  or Oracle Linux. I don't know if they are shipping ZFS support with it yet. But they are already shipping dtrace with it which suffers from the same license issues.
  - ryao 12y ago
    I asked the Oracle representative at LinuxCon North America 2014 this question and explicitly mentioned that it was already shipping CDDL kernel code because of DTrace. He could not answer this question, but claimed that he would get back to me. So far, I have not heard back.
    - fafner 12y ago
      They are currently using a trick trying to circumvent the EXPORT_SYMBOL_GPL issue. But it is highly dubious whether this is legally sound: ktime_t dtrace_gethrtime(void) { return ktime_get(); } EXPORT_SYMBOL(dtrace_gethrtime); http://mjg59.dreamwidth.org/31357.html http://mjg59.dreamwidth.org/31357.html In the end I assume this is intentional to keep the license issue of dtrace and ZFS in a dubious state. Thus preventing other distributions from shipping it. Meanwhile Oracle can ship it because they aren't going to sue themselves and the kernel folks seem rather uninterested in lawsuits as well (and even if they did then Oracle could drag it out forever considering that the company seems to have more lawyers than developers).

byuu 12y ago

So it sounds like they are okay with binary kernel modules, just not built-in to the base kernel. FreeBSD manages to do ZFS as a kernel module (plus another module for Open Solaris abstractions) quite successfully. Although it has somewhat of an ugly ZFS-on-root shim loader for booting from a ZFS partition, it does certainly get the job done. Here's hoping Debian can develop something similar so that users can create and boot from a ZFS partition during their installer. > CCDL is an Open Source License that is DFSG compliant I don't mean to nitpick, but if you're going to discuss the legalities of a license, at least spell it correctly. It's not CCDL, it's CDDL, or Common Development and Distribution License.

Thaxll 12y ago

I stopped using ZFS when I learn that using non ECC memory was dangerous and could corrupt sane data.

ryao 12y ago
The filesystem that you use has nothing to do with the opportunity for bit flips in non-ECC RAM to cause issues. If you are concerned about the effect of bit flips in non-ECC memory on filesystems, then the solution is to use only systems that have ECC memory. There is no other way to deal with that problem.
ChuckMcM 12y ago
I'm confused by this statement, using 'non ECC' memory is dangerous and does corrupt otherwise sane data. Using or not using ZFS doesn't change this danger.
- Thaxll 12y ago
  Other FS won't try to correct sane data on HDD but corrupted when loaded in memory.
  - ryao 12y ago
    You are describing what undefined behavior might manifest in response to a bit flip. It is undefined for the reason that anything can go wrong, although I have trouble seeing how the particular scenario you describe here would cause a problem. If the checksum verification fails on a read because of a bit flip in the data, ZFS will just load another copy. That being said, it is not a good idea to use hardware that lacks ECC RAM. No filesystem developer will claim that their kernel driver can operate properly without ECC RAM because it is not possible. Email the linux-fsdevel mailing list if you want confirmation.
  - XorNot 12y ago
    ZFS does not do this. Your assumptions about what other FSs do is inaccurate. Consider: you load data from ext4 into RAM, it gets corrupted. You change some bytes, then save it. Corrupted data is then written to the disk. Could be anything inside the allocation unit size, which is 4K generally - not insubstantial. ZFS's worst case behavior is exactly the same: it can't protect you from corruption in RAM after checksum validation if you then ask it to save that data to disk. There is no difference: if you do not have ECC RAM, you are vulnerable to bitflips corrupting your data - and they will have been. ZFS won't corrupt data which gets altered in memory due to a bitflip but is only ever read. It can't - because in-memory bitflips can't be detected. Even if at some point during checksum validation there was a mismatch, the restore is done from checksum protected parity/mirror image data. And if the restore block were corrupted, the checksum won't match and ZFS will rebuild the block correctly next time. If you do not have ECC RAM, every filesystem will potentially corrupt your data. ZFS is more resilient then pretty much all of them even in this case.