linux-kernel - Re: xfs: does mkfs.xfs require fancy switches to get decent performance? (was Tux3 Report: How fast can we fsync?)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20150513072053.GB19700@amd>
Date:	Wed, 13 May 2015 09:20:53 +0200
From:	Pavel Machek <pavel@....cz>
To:	Daniel Phillips <daniel@...nq.net>
Cc:	David Lang <david@...g.hm>, Theodore Ts'o <tytso@....edu>,
	Howard Chu <hyc@...as.com>, Dave Chinner <david@...morbit.com>,
	linux-kernel@...r.kernel.org,
	Mike Galbraith <umgwanakikbuti@...il.com>, tux3@...3.org,
	linux-fsdevel@...r.kernel.org,
	OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>
Subject: Re: xfs: does mkfs.xfs require fancy switches to get decent
 performance? (was Tux3 Report: How fast can we fsync?)

On Tue 2015-05-12 13:54:58, Daniel Phillips wrote:
> On 05/12/2015 11:39 AM, David Lang wrote:
> > On Mon, 11 May 2015, Daniel Phillips wrote:
> >>> ...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.
> 
> Perhaps you misunderstood. Linus decides what gets merged. Andrew
> decides. Greg decides. Dave Chinner does not decide, he just does
> his level best to create the impression that our project is unfit
> to merge. Any chance there might be an agenda?

Dunno. _Your_ agenda seems to be "attack other maintainers so much
that you can later claim they are biased".

Not going to work, sorry.

> > 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)
> 
> Yet he clearly wrote "we" as if he believes he is part of it.
> 
> Now that ENOSPC is done to a standard way beyond what Btrfs had
> when it was merged, the next item on the agenda is writeback. That
> involves us and VFS people as you say, and not Dave Chinner, who
> only intends to obstruct the process as much as he possibly can. He

Why would he do that? Aha, maybe because you keep attacking him all
the time. Or maybe because your code is not up to the kernel
standards. You want to claim it is the former, but it really looks
like the latter.

Just stop doing that. You are not creating nice atmosphere and you are
not getting tux3 being merged in any way.

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/