On Nov 22, 2010, at 12:41 PM, Stephen Joyce wrote: > Note that I just read about this on slashdot > <http://linux.slashdot.org/story/10/11/22/1433246/Running-ZFS-Natively-On-Linux-Slower-Than-Btrfs>, > which along with the cruft its discussions are wont to have, touches on > licensing issues. OpenAFS gets a mention (not by me).
After reading the article the slashdot item points to, I'd have to say their analysis is premature. It appears the system being tested broke off from LANL about a year back. The article says: "...We have seen the source code to the KQ Infotech work and as of right now it appears to have been branched from the Lawrence Livermore National Laboratories ZFS work at 2009-11-24. This is from the SPL/ZFS 0.4.9 release that was based upon OpenSolaris Nevada Build (ONNV) 121 with Zpool version 18 and file-system version 4. The upstream LLNL work is up to version 0.5.2 with ONNV Build 147, Zpool 28, and ZFS file-system version five. KQ Infotech has pulled in support right now for ZFS Zpool version 26, but before the January release they plan to rebase against Zpool 28." I did a quick perusal of the ZFS on Linux site (http://zfsonlinux.org/), the Pharonal review (http://www.phoronix.com/scan.php?page=article&item=linux_kqzfs_benchmarks&num=1), and the site from which Pharonal got their distro (http://zfs.kqinfotech.com/). My end opinion is 'why bother?' I can't see that KQ adds any value that would not have been better done by working more directly with LANL/ZFS on Linux, and a 'performance review' of a beta that itself is based on a year-old version of the LANL code is only slightly useful. Frankly, pharonal should have either waited two months for the LANL release or tested it as well. Steve_______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
