![]() So I don't have any particular iron in the fire. I don't run either I'm on ext4 and XFS, mostly. and it seemed appropriate to point out that it doesn't matter what technical features it has, if it doesn't work reliably. Rather, I replied because you were praising btrfs. I didn't reply because you were criticizing ZFS for the most part, I agree with the criticism. >Do we really need to point out the slow development process of Btrfs every time there is even a miniscule criticism of ZFS? Discussing the technical details of the two file systems doesn't need to turn into a spat. ![]() I just paid the ECC premium a couple months ago and it was painful. Because clearly if you want 16gb modules you are a business and can afford $800 for some memory. And the larger the module the worse the ECC premium. I was looking at 16gb modules and the ECC versions are just outrageously priced against regular unregistered memory, part of that is the new DDR4 standard that the haswell xeons use but the bulk is just the ECC premium.Ĭrucial 16GB (2 x 8GB) 240-Pin DDR3 SDRAM ECC = $169.99Ĭrucial Ballistix Sport 16GB (2 x 8GB) 240-Pin DDR3 = $124.99 And the more ECC memory you need the higher the premium. So you tack in the 30% price premium on the modules, the $50-$100 for the motherboard and another $100-$200 for a specific processor that works with ECC and you're up to a $300-$500 addon. AFAIK all of the motherboards will disable ECC unless certain processors are installed. Intel is contractually limiting which processors can work with ECC. I still have a faint hope that Btrfs will one day get to the same quality of implementation as ZFS, but until then it really is a poor substitute for ZFS. Overall, very happy with the documentation and tools compared with the Btrfs equivalents. Recently I supplemented the HDD RAID array with SSDs for L2ARC and ZIL. Data corruption, unrecoverable raid mirrors leading to complete dataloss, repeated unbalancing to unusability.Ī year ago I moved all my data onto an HP N40L microserver with 6GB RAM using ZFS on FreeBSD 10.0 (now 10.1). I've been bitten time and time again with Btrfs issues. ZFS, in comparison, has an excellent reputation. I've gotten to the point now that I wonder if it'll ever really be stable. > Which is cool, but not being ready for production use after all these years is quite the drawback. >Btrfs does not: It has no greater memory requirements for basic use than any other Linux file system because it properly uses the VFS for its heavy lifting and doesn't depend on cache to satisfy basic performance demands. For deduplication, both file systems incur substantial additional memory requirements, but that's not what the 8GiB recommendation addresses. Btrfs does not: It has no greater memory requirements for basic use than any other Linux file system because it properly uses the VFS for its heavy lifting and doesn't depend on cache to satisfy basic performance demands. ![]() ZFS has obscene (and I don't use the word lightly) memory requirements in basic use cases. Again, ARC is a wonderful algorithm, but at least in my opinion, it's not so great to be bundled as an integral part of a file system. ZFS is such a special snowflake that a file system needs memory management that doesn't play nice with the OS. Perhaps Oracle has a license or a sufficient patent portfolio to protect Solaris and Unbreakable Linux users, but the CDDL does not confer any patent protection for ZoL or FreeBSD users.Īnyways, back to the memory issue. It's a fantastic algorithm, but it certainly violates IBM patents, which is why it was removed from PostgreSQL and omitted from Linux. The reason why ZFS requires so much memory is because it includes its own separate cache system based on the ARC algorithm.
0 Comments
Leave a Reply. |