Received-SPF: pass (google.com: domain of linux-nfs+bounces-3376-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Precedence: bulk
MIME-Version: 1.0
References: <20240523165436.g5xgo7aht7dtmvfb@quack3>
In-Reply-To: <20240523165436.g5xgo7aht7dtmvfb@quack3>
From: Dan Shelton <dan.f.shelton@gmail.com>
Date: Fri, 24 May 2024 19:08:51 +0200
Message-ID: <CAAvCNcB1hsS67Cy6sZP3Mf33VCKfFsg0Vc0pH2XJt0K6Po9ZQQ@mail.gmail.com>
Subject: Re: Bad NFS performance for fsync(2)
To: Jan Kara <jack@suse.cz>
Cc: 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>
Content-Type: text/plain; charset="UTF-8"

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?

Dan
-- 
Dan Shelton - Cluster Specialist Win/Lin/Bsd