Received-SPF: pass (google.com: domain of linux-nfs+bounces-3400-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
Date: Mon, 27 May 2024 12:32:33 +0200
From: Jan Kara <jack@suse.cz>
To: Dan Shelton <dan.f.shelton@gmail.com>
Cc: Jan Kara <jack@suse.cz>, linux-nfs@vger.kernel.org,
	Chuck Lever <chuck.lever@oracle.com>,
	Jeff Layton <jlayton@kernel.org>,
	Trond Myklebust <trond.myklebust@hammerspace.com>,
	Anna Schumaker <anna@kernel.org>
Subject: Re: Bad NFS performance for fsync(2)
Message-ID: <20240527103233.yuwrdjcdfs7lewed@quack3>
References: <20240523165436.g5xgo7aht7dtmvfb@quack3>
 <CAAvCNcB1hsS67Cy6sZP3Mf33VCKfFsg0Vc0pH2XJt0K6Po9ZQQ@mail.gmail.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAAvCNcB1hsS67Cy6sZP3Mf33VCKfFsg0Vc0pH2XJt0K6Po9ZQQ@mail.gmail.com>

On Fri 24-05-24 19:08:51, Dan Shelton wrote:
> On Thu, 23 May 2024 at 18:55, Jan Kara <jack@suse.cz> wrote:
> >
> > Hello!
> >
> > I've been debugging NFS performance regression with recent kernels. It
> > seems to be at least partially related to the following behavior of NFS
> > (which is there for a long time AFAICT). Suppose the following workload:
> >
> > fio --direct=0 --ioengine=sync --thread --directory=/test --invalidate=1 \
> >   --group_reporting=1 --runtime=100 --fallocate=posix --ramp_time=10 \
> >   --name=RandomWrites-async --new_group --rw=randwrite --size=32000m \
> >   --numjobs=4 --bs=4k --fsync_on_close=1 --end_fsync=1 \
> >   --filename_format='FioWorkloads.$jobnum'
> 
> Where do you get the fio command from?

Well, this is somewhat hand-edited fio command that our QA runs as part of
performance testing of our kernels.

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR