From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1S1Obv-0004MB-Ff for garchives@archives.gentoo.org; Sat, 25 Feb 2012 20:52:55 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 44F32E0D2A; Sat, 25 Feb 2012 20:52:46 +0000 (UTC) Received: from edge2.cs.stonybrook.edu (edge2.cs.stonybrook.edu [130.245.9.211]) by pigeon.gentoo.org (Postfix) with ESMTP id 99C83E0B6B for ; Sat, 25 Feb 2012 20:52:18 +0000 (UTC) Received: from HUBCAS1.cs.stonybrook.edu (130.245.9.206) by edge2.cs.stonybrook.edu (130.245.9.211) with Microsoft SMTP Server (TLS) id 14.1.355.2; Sat, 25 Feb 2012 15:52:12 -0500 Received: from mail-iy0-f181.google.com (209.85.210.181) by hubcas1.cs.stonybrook.edu (130.245.9.212) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sat, 25 Feb 2012 15:52:17 -0500 Received: by iaoo28 with SMTP id o28so927490iao.40 for ; Sat, 25 Feb 2012 12:52:15 -0800 (PST) Received-SPF: pass (google.com: domain of ryao@cs.stonybrook.edu designates 10.50.89.196 as permitted sender) client-ip=10.50.89.196; Authentication-Results: mr.google.com; spf=pass (google.com: domain of ryao@cs.stonybrook.edu designates 10.50.89.196 as permitted sender) smtp.mail=ryao@cs.stonybrook.edu Received: from mr.google.com ([10.50.89.196]) by 10.50.89.196 with SMTP id bq4mr10146381igb.26.1330203135570 (num_hops = 1); Sat, 25 Feb 2012 12:52:15 -0800 (PST) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Received: by 10.50.89.196 with SMTP id bq4mr8109229igb.26.1330203135555; Sat, 25 Feb 2012 12:52:15 -0800 (PST) Received: by 10.231.29.38 with HTTP; Sat, 25 Feb 2012 12:52:15 -0800 (PST) In-Reply-To: References: <4F47CF5C.4070508@gentoo.org> <20120224154327.61c051ad@gentoo.org> <3a6095b4d48c4163bb912d6fd608059f@HUBCAS2.cs.stonybrook.edu> Date: Sat, 25 Feb 2012 15:52:15 -0500 Message-ID: Subject: Re: [gentoo-dev] preserve_old_lib and I'm even more lazy From: Richard Yao To: "gentoo-dev@lists.gentoo.org" Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-Originating-IP: [209.85.210.181] X-Archives-Salt: 1ab85ef8-686d-45ca-b5ce-e99bf2b81f17 X-Archives-Hash: afd6c15709b268e7db3e5491bb8d86c5 > Oh, if you need a safe COW filesystem today I'd definitely recommend > ZFS over btrfs for sure, although I suspect the people who are most > likely to take this sort of advice are also the sort of people who are > most likely to not be running Gentoo. =A0There are a bazillion problems > with btrfs as it stands. There is significant interest in ZFS in the Gentoo community, especially on freenode. Several veteran users are evaluating it and others have already begun to switch from other filesystems, volume managers and RAID solutions. > However, fundamentally there is no reason to think that ZFS will > remain better in the future, once the bugs are worked out. =A0They're > still focusing on keeping btrfs from hosing your data - tuning > performance is not a priority yet. =A0However, the b-tree design of > btrfs should scale very well once the bugs are worked out. ZFSOnLinux performance tuning is not a priority either, but there have been a few patches and the performance is good. btrfs might one day outperform ZFS in terms of single disk performance, assuming that it does not already, but I question the usefulness of single disk performance as a performance metric. If I add a SSD to a ZFS pool machine to complement the disk, system performance will increase many-fold. As far as I can tell, that will never be possible with btrfs without external solutions like Google's flashcache, which killed an OCZ Vertex 3 within 16 days about a month ago that Wyatt in #gentoo-chat on freenode had to replace. I imagine that its death could have been delayed through write rate limiting, which is what ZFS uses for L2ARC, but until you can replace the Linux page replacement algorithm with either ARC or something comparable, flashcache will be inferior to ZFS L2ARC. You can read more about this topic at the following link: http://linux-mm.org/AdvancedPageReplacement ZFS at its core is a transactional object store and everything that enables its use as a filesystem is implemented on top of that. ZFS supports raidz3, zvols, L2ARC, SLOG/ZIL and endian independence, which as far as I can tell, are things that btrfs will never support.. ZFS also has either first-party or third-party support on Solaris, FreeBSD, Linux, Mac OS X and Windows, while btrfs appears to have no future outside of Linux. Lastly, ZFS' performance scaling exceeds that of any block device based filesystem I have seen (which excludes comparisons with tmpfs/ramfs and lustre/gpfs). The following benchmark is of a SAN device using ZFS: http://www.anandtech.com/show/3963/zfs-building-testing-and-benchmarking/2 While ZFS performance in that benchmark is impressive, ZFS can scale far higher with additional disks and more SSDs. SuperMicro has a hotswappable 72-disk enclosure that should enable ZFS to far exceed the performance of the system that Anandtech benchmarked, provided that it is configured with a large ARC cache and multiple vdevs each with multiple disks, some SSDs for L2ARC and a SLC SSD-based SLOG/ZIL. I would not be surprised if ZFS performance were to exceed 1 million IOPS on such hardware. Nothing that I have seen planned for btrfs can perform comparably, in any configuration.