71–80 of 86 posts
I run it on a NAS with 4G of memory, and I've had to limit usage and flush caches occasionally, otherwise I get to the point that I can't run new programs.
Earlier quoted context omitted.
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 featur…
As for bmap, I can say unequivocally that bmap will never be supported in ZFS. bmap is a nonstandard extension that is incompatible with filesystems that span multiple disks, incompatible with network filesystems that have no local disks and incompatible when doing writes to filesystems that support checksums. ZFS is disqualified from supporting bmap by virtue of #1 and #3. The same is true for others such as btrfs and NFS.
As for O_DIRECT, there are no clearly defined semantics for O_DIRECT other than how it is implemented in XFS. My understanding of O_DIRECT is that the I/O is intended to go straight to/from the underlying disk. A true implementation of those semantics cannot be implemented in filesystem that spans multiple disks, CoW or checksums. A lesser form could probably be implemented where we try to make I/Os using O_DIRECT operate as if they were run with primarycache=metadata when primarycache=data and secondarycache=metadata when secondarycache=data. A third option would be to just ignore the O_DIRECT flag. A fourth would be to let users choose between the second and third. We might support that in the future, but I am inclined to think it will do more harm than good.
As for why NFS is in the VFS API support chart, NFS is least common denominator for VFS API support that is widely deployed. Nearly all software that works on NFS can be known to work on other filesystems. Those using the chart for its intended purpose can quickly deduce whether software will likely run on ZFSOnLinux when they know that it already works on NFS. The sole exceptions are software that uses O_DIRECT or NFSv4 ACLs. The former can typically be toggled on/off in software that supports it while the latter can be dismissed with the knowledge that it runs on NFSv3 (or any other Linux filesystem at the present time).
Can anyone point me to a guide for migrating from software RAID to ZoL?
http://zfsonlinux.org/lists.html
The answer to your question depends on your existing setup.
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?
All the extra stuff ZFS does, and does performantly, comes at a cost. That's the cost (I can't vouch for the amount.. but the principle is right. CPU power matters too.) You don't get all those features for free... but you do get them.
https://github.com/zfsonlinux/spl/pull/369#issuecomment-5839...
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.
https://news.ycombinator.com/item?id=8438416
Would you provide a link to that guide? If there is a guide out there that says that you should use something other than ZFS when a system lacks ECC, I would like to know so that I can try to get it corrected.
Not using ZFS because it cannot provide full protection without ECC is like not getting a flu shot because you can still get sick anyway. It is true, but opting to be even less safe in the name of safety is counterproductive.
Probably OK for home use, but not much more. Even a small startup with no patents could end up getting bought by a larger company that does have patents. Then that company could be vulnerable, perhaps even if they are trying to use their patents defensively.
Earlier quoted context omitted.
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…
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 lead to compounding corruption as described in the blog post I linked. Hence the ongoing(?) debate in the ZFS community.
However, I consider myself disqualified from this discussion and sorry again for my tone. I'll read up on the current state of the argument.