From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Phillips Subject: Re: xfs: does mkfs.xfs require fancy switches to get decent performance? (was Tux3 Report: How fast can we fsync?) Date: Mon, 11 May 2015 23:18:49 -0700 Message-ID: <55519B49.8040605@phunq.net> References: <1430395641.3180.94.camel@gmail.com> <1430401693.3180.131.camel@gmail.com> <55423732.2070509@phunq.net> <55423C05.1000506@symas.com> <554246D7.40105@phunq.net> <20150511221223.GD4434@amd> <20150511231714.GD14088@thunk.org> <555166BA.1050606@phunq.net> <20150512053842.GH15721@dastard> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: Theodore Ts'o , Howard Chu , linux-kernel@vger.kernel.org, Mike Galbraith , Pavel Machek , tux3@tux3.org, linux-fsdevel@vger.kernel.org, OGAWA Hirofumi To: Dave Chinner Return-path: In-Reply-To: <20150512053842.GH15721@dastard> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tux3-bounces@phunq.net Sender: "Tux3" List-Id: linux-fsdevel.vger.kernel.org On Monday, May 11, 2015 10:38:42 PM PDT, Dave Chinner wrote: > I think Ted and I are on the same page here. "Competitive > benchmarks" only matter to the people who are trying to sell > something. You're trying to sell Tux3, but.... By "same page", do you mean "transparently obvious about obstructing other projects"? > The "except page forking design" statement is your biggest hurdle > for getting tux3 merged, not performance. No, the "except page forking design" is because the design is already good and effective. The small adjustments needed in core are well worth merging because the benefits are proved by benchmarks. So benchmarks are key and will not stop just because you don't like the attention they bring to XFS issues. > Without page forking, tux3 > cannot be merged at all. But it's not filesystem developers you need > to convince about the merits of the page forking design and > implementation - it's the mm and core kernel developers that need to > review and accept that code *before* we can consider merging tux3. Please do not say "we" when you know that I am just as much a "we" as you are. Merging Tux3 is not your decision. The people whose decision it actually is are perfectly capable of recognizing your agenda for what it is. http://www.phoronix.com/scan.php?page=news_item&px=MTA0NzM "XFS Developer Takes Shots At Btrfs, EXT4" The real question is, has the Linux development process become so political and toxic that worthwhile projects fail to benefit from supposed grassroots community support. You are the poster child for that. > IOWs, you need to focus on the important things needed to acheive > your stated goal of getting tux3 merged. New filesystems should be > faster than those based on 20-25 year old designs, so you don't need > to waste time trying to convince people that tux3, when complete, > will be fast. You know that Tux3 is already fast. Not just that of course. It has a higher standard of data integrity than your metadata-only journalling filesystem and a small enough code base that it can be reasonably expected to reach the quality expected of an enterprise class filesystem, quite possibly before XFS gets there. Regards, Daniel