From: Dave Chinner <david@fromorbit.com>
To: "Darrick J. Wong" <darrick.wong@oracle.com>
Cc: Murphy Zhou <jencce.kernel@gmail.com>,
linux-xfs@vger.kernel.org, linux-nfs@vger.kernel.org
Subject: Re: A NFS, xfs, reflink and rmapbt story
Date: Tue, 28 Jan 2020 10:56:17 +1100 [thread overview]
Message-ID: <20200127235617.GB18610@dread.disaster.area> (raw)
In-Reply-To: <20200124011019.GA8247@magnolia>
On Thu, Jan 23, 2020 at 05:10:19PM -0800, Darrick J. Wong wrote:
> On Thu, Jan 23, 2020 at 04:32:17PM +0800, Murphy Zhou wrote:
> > Hi,
> >
> > Deleting the files left by generic/175 costs too much time when testing
> > on NFSv4.2 exporting xfs with rmapbt=1.
> >
> > "./check -nfs generic/175 generic/176" should reproduce it.
> >
> > My test bed is a 16c8G vm.
>
> What kind of storage?
Is the NFS server the same machine as what the local XFS tests were
run on?
> > NFSv4.2 rmapbt=1 24h+
>
> <URK> Wow. I wonder what about NFS makes us so slow now? Synchronous
> transactions on the inactivation? (speculates wildly at the end of the
> workday)
Doubt it - NFS server uses ->commit_metadata after the async
operation to ensure that it is completed and on stable storage, so
the truncate on inactivation should run at pretty much the same
speed as on a local filesystem as it's still all async commits. i.e.
the only difference on the NFS server is the log force that follows
the inode inactivation...
> I'll have a look in the morning. It might take me a while to remember
> how to set up NFS42 :)
>
> --D
>
> > NFSv4.2 rmapbt=0 1h-2h
> > xfs rmapbt=1 10m+
> >
> > At first I thought it hung, turns out it was just slow when deleting
> > 2 massive reflined files.
Both tests run on the scratch device, so I don't see where there is
a large file unlink in either of these tests.
In which case, I'd expect that all the time is consumed in
generic/176 running punch_alternating to create a million extents
as that will effectively run a synchronous server-side hole punch
half a million times.
However, I'm guessing that the server side filesystem has a very
small log and is on spinning rust, hence the ->commit_metadata log
forces are preventing in-memory aggregation of modifications. This
results in the working set of metadata not fitting in the log and so
each new hole punch transaction ends up waiting on log tail pushing
(i.e. metadata writeback IO). i.e. it's thrashing the disk, and
that's why it is slow.....
Storage details, please!
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
next prev parent reply other threads:[~2020-01-27 23:56 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-23 8:32 A NFS, xfs, reflink and rmapbt story Murphy Zhou
2020-01-24 1:10 ` Darrick J. Wong
2020-01-27 22:36 ` J. Bruce Fields
2020-02-05 6:22 ` Murphy Zhou
2020-02-16 8:28 ` Murphy Zhou
2020-02-17 0:36 ` J. Bruce Fields
2020-01-27 23:56 ` Dave Chinner [this message]
2020-02-05 6:52 ` Murphy Zhou
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=20200127235617.GB18610@dread.disaster.area \
--to=david@fromorbit.com \
--cc=darrick.wong@oracle.com \
--cc=jencce.kernel@gmail.com \
--cc=linux-nfs@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
/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).