xfs: does mkfs.xfs require fancy switches to get decent performance? (was Tux3 Report: How fast can we fsync?)
Elifarley Callado Coelho Cruz
elifarley at gmail.com
Wed May 13 06:47:44 PDT 2015
May I suggest a very relevant reading to all, even though the subject is
not file systems nor kernel development:
Rogerian Argument - Solving Problems by Negotiating Differences (academic
Besides, I thinks everyone would benefit a lot more if most (if not ALL) of
emotionally loaded sentences were simply omitted from technical discussions.
Please don't use words like "crowing", "stinky" and so on. I mean, what
kind of technical advance can be achieved by using that ?
Instead of "stinky", say "your argument is false because [then provide the
minimum set of accurate logical details needed to get your point across,
nothing more, nothing else]"
Appeal to rubber ducking instead if you really need to vent.
I think all of this is valid for any technical discussion.
" Do not believe anything because it is said by an authority, or if it is
said to come from angels, or from Gods, or from an inspired source.
Believe it only if you have explored it in your own heart and mind and body
and found it to be true. Work out your own path, through diligence."
- Gautama Buddha
On Wed, May 13, 2015 at 4:20 AM, Pavel Machek <pavel at ucw.cz> wrote:
> 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.
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures)
> Tux3 mailing list
> Tux3 at phunq.net
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Tux3