From: David Lang <david@lang.hm>
To: Daniel Phillips <daniel@phunq.net>
Cc: Dave Chinner <david@fromorbit.com>,
"Theodore Ts'o" <tytso@mit.edu>, Pavel Machek <pavel@ucw.cz>,
Howard Chu <hyc@symas.com>,
Mike Galbraith <umgwanakikbuti@gmail.com>,
linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
tux3@tux3.org, OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
Subject: Re: xfs: does mkfs.xfs require fancy switches to get decent performance? (was Tux3 Report: How fast can we fsync?)
Date: Tue, 12 May 2015 11:39:03 -0700 (PDT) [thread overview]
Message-ID: <alpine.DEB.2.02.1505121111230.644@nftneq.ynat.uz> (raw)
In-Reply-To: <55519B49.8040605@phunq.net>
On Mon, 11 May 2015, Daniel Phillips wrote:
> 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"
umm, Phoronix has no input on what gets merged into the kernel. they also hae a
reputation for trying to turn anything into click-bait by making it sound like a
fight when it isn't.
> 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.
The linux development process is making code available, responding to concerns
from the experts in the community, and letting the code talk for itself.
There have been many people pushing code for inclusion that has not gotten into
the kernel, or has not been used by any distros after it's made it into the
kernel, in spite of benchmarks being posted that seem to show how wonderful the
new code is. ReiserFS was one of the first, and part of what tarnished it's
reputation with many people was how much they were pushing the benchmarks that
were shown to be faulty (the one I remember most vividly was that the entire
benchmark completed in <30 seconds, and they had the FS tuned to not start
flushing data to disk for 30 seconds, so the entire 'benchmark' ran out of ram
without ever touching the disk)
So when Ted and Dave point out problems with the benchmark (the difference in
behavior between a single spinning disk, different partitions on the same disk,
SSDs, and ramdisks), you would be better off acknowledging them and if you can't
adjust and re-run the benchmarks, don't start attacking them as a result.
As Dave says above, it's not the other filesystem people you have to convince,
it's the core VFS and Memory Mangement folks you have to convince. You may need
a little benchmarking to show that there is a real advantage to be gained, but
the real discussion is going to be on the impact that page forking is going to
have on everything else (both in complexity and in performance impact to other
things)
>> 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.
We wouldn't expect anyone developing a new filesystem to believe any
differently. If they didn't believe this, why would they be working on the
filesystem instead of just using an existing filesystem.
The ugly reality is that everyone's early versions of their new filesystem looks
really good. The problem is when they extend it to cover the corner cases and
when it gets stressed by real-world (as opposed to benchmark) workloads. This
isn't saying that you are wrong in your belief, just that you may not be right,
and nobody will know until you are to a usable state and other people can start
beating on it.
David Lang
next prev parent reply other threads:[~2015-05-12 18:39 UTC|newest]
Thread overview: 160+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-28 23:13 Tux3 Report: How fast can we fsync? Daniel Phillips
2015-04-29 2:21 ` Mike Galbraith
2015-04-29 6:01 ` Daniel Phillips
2015-04-29 6:20 ` Richard Weinberger
2015-04-29 6:56 ` Daniel Phillips
2015-04-29 6:33 ` Mike Galbraith
2015-04-29 7:23 ` Daniel Phillips
2015-04-29 16:42 ` Mike Galbraith
2015-04-29 19:05 ` xfs: does mkfs.xfs require fancy switches to get decent performance? (was Tux3 Report: How fast can we fsync?) Mike Galbraith
2015-04-29 19:20 ` Austin S Hemmelgarn
2015-04-29 21:12 ` Daniel Phillips
2015-04-30 4:40 ` Mike Galbraith
2015-04-30 0:20 ` Dave Chinner
2015-04-30 3:35 ` Mike Galbraith
2015-04-30 9:00 ` Martin Steigerwald
2015-04-30 14:57 ` Theodore Ts'o
2015-04-30 15:59 ` Daniel Phillips
2015-04-30 17:59 ` Martin Steigerwald
2015-04-30 11:14 ` Daniel Phillips
2015-04-30 12:07 ` Mike Galbraith
2015-04-30 12:58 ` Daniel Phillips
2015-04-30 13:48 ` Mike Galbraith
2015-04-30 14:07 ` Daniel Phillips
2015-04-30 14:28 ` Howard Chu
2015-04-30 15:14 ` Daniel Phillips
2015-04-30 16:00 ` Howard Chu
2015-04-30 18:22 ` Christian Stroetmann
2015-05-11 22:12 ` Pavel Machek
2015-05-11 23:17 ` Theodore Ts'o
2015-05-12 2:34 ` Daniel Phillips
2015-05-12 5:38 ` Dave Chinner
2015-05-12 6:18 ` Daniel Phillips
2015-05-12 18:39 ` David Lang [this message]
2015-05-12 20:54 ` Daniel Phillips
2015-05-12 21:30 ` David Lang
2015-05-12 22:27 ` Daniel Phillips
2015-05-12 22:35 ` David Lang
2015-05-12 23:55 ` Theodore Ts'o
2015-05-13 1:26 ` Daniel Phillips
2015-05-13 19:09 ` Martin Steigerwald
2015-05-13 19:37 ` Daniel Phillips
2015-05-13 20:02 ` Jeremy Allison
2015-05-13 20:24 ` Daniel Phillips
2015-05-13 20:25 ` Martin Steigerwald
2015-05-13 20:38 ` Daniel Phillips
2015-05-13 21:10 ` Martin Steigerwald
2015-05-13 0:31 ` Daniel Phillips
2015-05-12 21:30 ` Christian Stroetmann
2015-05-13 7:20 ` Pavel Machek
2015-05-13 13:47 ` Elifarley Callado Coelho Cruz
2015-05-12 9:03 ` Pavel Machek
2015-05-12 11:22 ` Daniel Phillips
2015-05-12 13:26 ` Howard Chu
2015-05-11 23:53 ` Daniel Phillips
2015-05-12 0:12 ` David Lang
2015-05-12 4:36 ` Daniel Phillips
2015-05-12 17:30 ` Christian Stroetmann
2015-05-13 7:25 ` Pavel Machek
2015-05-13 11:31 ` Daniel Phillips
2015-05-13 12:41 ` Daniel Phillips
2015-05-13 13:08 ` Mike Galbraith
2015-05-13 13:15 ` Daniel Phillips
2015-04-30 14:33 ` Mike Galbraith
2015-04-30 15:24 ` Daniel Phillips
2015-04-29 20:40 ` Tux3 Report: How fast can we fsync? Daniel Phillips
2015-04-29 22:06 ` OGAWA Hirofumi
2015-04-30 3:57 ` Mike Galbraith
2015-04-30 3:50 ` Mike Galbraith
2015-04-30 10:59 ` Daniel Phillips
2015-04-30 1:46 ` Dave Chinner
2015-04-30 10:28 ` Daniel Phillips
2015-05-01 15:38 ` Dave Chinner
2015-05-01 23:20 ` Daniel Phillips
2015-05-02 1:07 ` David Lang
2015-05-02 10:26 ` Daniel Phillips
2015-05-02 16:00 ` Christian Stroetmann
2015-05-02 16:30 ` Richard Weinberger
2015-05-02 17:00 ` Christian Stroetmann
2015-05-12 17:41 ` Daniel Phillips
2015-05-12 17:46 ` Tux3 Report: How fast can we fail? Daniel Phillips
2015-05-13 22:07 ` Daniel Phillips
2015-05-26 10:03 ` Pavel Machek
2015-05-27 6:41 ` Mosis Tembo
2015-05-27 18:28 ` Daniel Phillips
2015-05-27 21:39 ` Pavel Machek
2015-05-27 22:46 ` Daniel Phillips
2015-05-28 12:55 ` Austin S Hemmelgarn
2015-05-27 7:37 ` Mosis Tembo
2015-05-27 14:04 ` Austin S Hemmelgarn
2015-05-27 15:21 ` Mosis Tembo
2015-05-27 15:37 ` Austin S Hemmelgarn
2015-05-14 7:37 ` [WIP] tux3: Optimized fsync Daniel Phillips
2015-05-14 8:26 ` [FYI] tux3: Core changes Daniel Phillips
2015-05-14 12:59 ` Rik van Riel
2015-05-15 0:06 ` Daniel Phillips
2015-05-15 3:06 ` Rik van Riel
2015-05-15 8:09 ` Mel Gorman
2015-05-15 9:54 ` Daniel Phillips
2015-05-15 11:00 ` Mel Gorman
2015-05-16 22:38 ` David Lang
2015-05-18 12:57 ` Mel Gorman
2015-05-15 9:38 ` Daniel Phillips
2015-05-27 7:41 ` Pavel Machek
2015-05-27 18:09 ` Daniel Phillips
2015-05-27 21:37 ` Pavel Machek
2015-05-27 22:33 ` Daniel Phillips
2015-05-15 8:05 ` Mel Gorman
2015-05-17 13:26 ` Boaz Harrosh
2015-05-18 2:20 ` Rik van Riel
2015-05-18 7:58 ` Boaz Harrosh
2015-05-19 4:46 ` Daniel Phillips
2015-05-21 19:43 ` [WIP][PATCH] tux3: preliminatry nospace handling Daniel Phillips
2015-05-19 14:00 ` [FYI] tux3: Core changes Jan Kara
2015-05-19 19:18 ` Daniel Phillips
2015-05-19 20:33 ` David Lang
2015-05-20 14:44 ` Jan Kara
2015-05-20 16:22 ` Daniel Phillips
2015-05-20 18:01 ` David Lang
2015-05-20 19:53 ` Rik van Riel
2015-05-20 22:51 ` Daniel Phillips
2015-05-21 3:24 ` Daniel Phillips
2015-05-21 3:51 ` David Lang
2015-05-21 19:53 ` Daniel Phillips
2015-05-26 4:25 ` Rik van Riel
2015-05-26 4:30 ` Daniel Phillips
2015-05-26 6:04 ` David Lang
2015-05-26 6:11 ` Daniel Phillips
2015-05-26 6:13 ` David Lang
2015-05-26 8:09 ` Daniel Phillips
2015-05-26 10:13 ` Pavel Machek
2015-05-26 7:09 ` Jan Kara
2015-05-26 8:08 ` Daniel Phillips
2015-05-26 9:00 ` Jan Kara
2015-05-26 20:22 ` Daniel Phillips
2015-05-26 21:36 ` Rik van Riel
2015-05-26 21:49 ` Daniel Phillips
2015-05-27 8:41 ` Jan Kara
2015-06-21 15:36 ` OGAWA Hirofumi
2015-06-23 16:12 ` Jan Kara
2015-07-05 12:54 ` OGAWA Hirofumi
2015-07-09 16:05 ` Jan Kara
2015-07-31 4:44 ` OGAWA Hirofumi
2015-07-31 15:37 ` Raymond Jennings
2015-07-31 17:27 ` Daniel Phillips
2015-07-31 18:29 ` David Lang
2015-07-31 18:43 ` Daniel Phillips
2015-07-31 22:12 ` Daniel Phillips
2015-07-31 22:27 ` David Lang
2015-08-01 0:00 ` Daniel Phillips
2015-08-01 0:16 ` Daniel Phillips
2015-08-03 13:07 ` Jan Kara
2015-08-01 10:55 ` Elifarley Callado Coelho Cruz
2015-08-18 16:39 ` Rik van Riel
2015-08-03 13:42 ` Jan Kara
2015-08-09 13:42 ` OGAWA Hirofumi
2015-08-10 12:45 ` Jan Kara
2015-08-16 19:42 ` OGAWA Hirofumi
2015-05-26 10:22 ` Sergey Senozhatsky
2015-05-26 12:33 ` Jan Kara
2015-05-26 19:18 ` Daniel Phillips
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.DEB.2.02.1505121111230.644@nftneq.ynat.uz \
--to=david@lang.hm \
--cc=daniel@phunq.net \
--cc=david@fromorbit.com \
--cc=hirofumi@mail.parknet.co.jp \
--cc=hyc@symas.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pavel@ucw.cz \
--cc=tux3@tux3.org \
--cc=tytso@mit.edu \
--cc=umgwanakikbuti@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).