I have been inundated with feedback from a wide number of channels. If I did not reply to a comment today, I will try to address it tomorrow.
The State of ZFS on Linux
91–100 of 125 posts
Re: The State of ZFS on Linux
#92Putting production data on a driver maintained outside the mainline Linux kernel is a bad idea. That isn't a licensing argument - I'm happy to use a proprietary nvidia.ko for gaming tasks, for example, because I won't be screwing up anyone's data if it breaks.
You could be "screwing up" someone's data if an in-tree filesystem breaks. If you read the supplementary blog posts, you would have seen the following:
http://lwn.net/Articles/437284/
Nearly all in-tree filesystems can fail in the same way described there. ZFS cannot. That being said, no filesystem is a replacement for backups. This applies whether you use ZFS or not. If you care about your data, you should have backups.
Re: The State of ZFS on Linux
#93I've looked into ZFS before for distributions like freenas, is there any solution on the horizon for the massive memory requirements? For example, needing 8-16gb ram for something like a xTB home nas is high.
The "massive memory requirements" only exist if you use data deduplication and care about write performance. Otherwise, ZFS does not require very much memory to run. It has a reputation to the contrary because ARC's memory usage is not shown as cache in the kernel's memory accounting, even though it is cache. This is in integration issue that would need to be addressed in Linus' tree.
Re: The State of ZFS on Linux
#94I have a laptop running ubuntu with a single SSD. Does it make sense to run it with ZFS to get compression and snapshots? If I add a hard drive, again does it make sense (perhaps using SSD as cache (arc?) )
Yes to using ZFS for your root drive. Probably no to using L2ARC in a laptop.
Re: The State of ZFS on Linux
#95I have a laptop running ubuntu with a single SSD. Does it make sense to run it with ZFS to get compression and snapshots? If I add a hard drive, again does it make sense (perhaps using SSD as cache (arc?) )
I've never heard of someone using ZFS with a single disk. You're probably better off with ext4. The compression and deduplication features of ZFS is terrific on network filers. Compression could possibly improve performance slightly on a single disk system. With two disks, I'd say you'd probably be better off with running RAID0 (or no RAID at all) and having a great backup plan. Using another SSD to cache writes to a…
I use it as my laptop's root filesystem. It works well for me. Here is a link to notes on how I installed it:
Re: The State of ZFS on Linux
#96Earlier quoted context omitted.
Without the needed support from the kernel side Can you clarify what you mean by that?
Basically I mean integration with the kernel's code base and all of the testing that entails. After their initial development, file systems all end up migrating to the kernel's code base. So, I'm not thinking in terms of technical API support, but more development/testing/integration support.
That is not a requirement. ZoL has the most sophisticated build system of any Linux kernel module in the world to enable it to live outside of the main tree. ZoL relies on autotools' API checks to do this. In addition, the project has an automated buildbot that helps us to detect regressions in pull requests before they are merged. It is similar in principle to how lustre filesystem development is done. Lustre is also (primarily) outside of the tree and lived entirely outside of the tree for years.
That being said, being inside the kernel source tree is not necessarily a good thing. As I wrote in the blog post, other filesystems on Linux generally do not provide the latest code to older kernels, but ZoL provides the latest code to all supported kernels and distributions. This ranges from Linux 2.6.26.y to the 3.16.y in 0.6.3 and will include 3.17.y in 0.6.4. Something as important as a filesystem should be updated to fix bugs, even if the kernel proper cannot be. The inability of all Linux systems to update to the latest kernel is an issue that Linus Torvalds mentioned at LinuxCon North America 2014 and ZoL is one of the few filesystems that can deal with it on systems where it is deployed.
Re: The State of ZFS on Linux
#97Earlier quoted context omitted.
The previous poster clearly does not understand that ZFS on Linux is essentially a native port with very careful dancing around licensing borders.
The previous poster is well aware of what ZFS on Linux is. Licensing matters. It may not matter in terms of what I can do with my servers. I can compile ZFS and run it just fine on Linux. But you won't find Red Hat doing it. You won't find IBM doing it. Linus won't be adding it into the mainline tree anytime soon. This means that there may be "technical" solutions to getting ZFS running on Linux, but that also means…
I am working on tearing down barriers to this. Expect to see the fruit of that effort later this year.
That said, I do not consider absence from Linus' tree to be a barrier because being in Linus' tree limits the ability of end users to obtain bug fixes. That is a problem other filesystems have that I am happy to see ZFSOnLinux avoid.
Also, Linus Torvalds and I discussed the possibility of merging ZFS into his tree because of feedback like yours. In short, Linus has no interest in merging ZFS into his tree. Linus thinks that it might enable Oracle might sue people unless they provide a signed-off to confirm that the code is under the CDDL. He also thinks that the kernel signed off keeps Oracle from suing people over btrfs when software patents are a likely loophole.
Lastly, I realize that my statement about the signed off confirming that the code is under the CDDL might sound strange. However, there are two cases to consider. The first case involves source code. The GPL does not restrict the redistribution of source code, so there would be no problem. The second case is binaries, which the GPL does restrict in situations in which a court of law would consider to be a derived work. Being a module only option should be sufficient to deal with that. Linus did not seem to have any problem with that idea. However, he insists on Oracle's signed off with the preference that it be Larry Elison.
Re: The State of ZFS on Linux
#98Earlier quoted context omitted.
Can you speak more about why ZFS is better than BTRFS?
A btrfs versus ZFS comparison probably deserves a blog post of its own, but I will try to address your question. I wrote the following on this topic last year: https://groups.google.com/d/msg/funtoo-dev/g9OY_vqVpCM/VTKF8... However, significant time has passed and it requires some corrections to be current: 1. I have not heard of any recent data corruption issues in btrfs, although I have not looked into them lately.…
Metadata/data checksums are CRC-32C on all platforms and is per 4KB fs block. And ext4's (optional) checksumming also uses it. TCP is 16-bit and not CRC, although ethernet makes use of CRC-32. While SHA-2 is a cryptographic function and CRC-32C is not, and therefore inferior, as a checksum in the context of mostly but not entirely trusted hardware is adequate. It's also fast to the degree on modern hardware there's no point using nodatasum to disable it. Even 32-bit hardware handles it.
Btrfs send/receive snapshots are read-only. So you first take a read-only snapshot, send it and upon receive it's read-only. To make it rw, snapshot it (without -r), and optionally delete the ro snapshot.
I agree the kernel currency issue to get more urgent fixes is a problem for making filesystem usage friendly, in particular while development is heavy and backporting is non-trivial.
Re: The State of ZFS on Linux
#99Earlier quoted context omitted.
A btrfs versus ZFS comparison probably deserves a blog post of its own, but I will try to address your question. I wrote the following on this topic last year: https://groups.google.com/d/msg/funtoo-dev/g9OY_vqVpCM/VTKF8... However, significant time has passed and it requires some corrections to be current: 1. I have not heard of any recent data corruption issues in btrfs, although I have not looked into them lately.…
I got the impression somewhere that btrfs RAID 5/6 support allows, or will allow, new devices to be added to an existing RAID group. That's an important feature for home and small business users. Having to replace every drive in a RAID group to grow it, as ZFS requires, is painful and expensive. Fortunately, drives are cheap enough these days that you can just way oversize your pool to begin with. But anyone switchin…
You can add/delete devices from raid5/6 volumes now. The raid5/6 code is still experimental, in particular while detected problems are fixed on-the-fly to userspace, the fixes aren't written back to drives. That limitation applies to normal usage and scrubbing. A balance detects and fixes these.
Also the determination of a drive being "faulty" (in the md/mdadm sense) and how this gets communicated to userspace isn't in place. If it's in place for ZoL (?) that'd be a considerable difference, a bigger one than checksum algorithms in my opinion.
Re: The State of ZFS on Linux
#100Earlier quoted context omitted.
Re: [1], isn't that far too many drives in one RAIDZ? Referencing this: http://www.solarisinternals.com/wiki/index.php/ZFS_Best_Prac...
Yes and no. The optimal number for RAIDZ/Z1/Z2, claimed by many benchmarks, is (power of two count of drives) plus (number of drives for parity)[1], with the upper bound being the likelihood of another drive failing before rebuild can complete. There is a tradeoff of, for example, using 3 RAIDZs each with a third of the drives in your pool, or 1 RAIDZ3 using all the drives in your pool. In the first case, a rebuild t…
You're pretty wrong regarding performance here. In ZFS, performance is directly bounded by the number of vdevs given to a pool. If you make one 90 drive vdev, you are more or less limiting yourself to the iops of a single disk. It's a bit more complicated than that, as your throughput increases.
At work where we use ZFS extensively we more or less use # of vdevs * I/O performance of a single drive = total "worst-case" IOPS prior to caching. Caching of course is where ZFS will start to shine - it will win no performance crowns when put up against a "traditional" RAID6 array with the same number of spindles.
This is also why most production implementations of ZFS utilize many sets of mirrors. For example your 90 drive example would be 45 sets of mirrors in our environment, granting roughly 45*120 iops (if NL SAS) total peak capacity. We avoid RAIDZ largely for the reason it would drastically lower the total # of vdevs, and performance falls off a cliff in that situation.
ZFS (not on Linux) seems to handle up to around 300 drives fairly handily before you start to run into issues I've found. 280 is our current max cluster design.