From: Martin Cracauer <cracauer@cons.org>
To: linux-kernel@vger.kernel.org
Subject: Possibe NFS mm problem: client page-in errors with ZFS Linux server
Date: Mon, 11 Feb 2019 11:28:22 -0500 [thread overview]
Message-ID: <20190211162821.GA38018@cons.org> (raw)
Folks. I suspect that this isn't actually a ZFS bug but a general
memory manager problem. I would appreciate input from mm folks. I
parked the detailed bug report here for now:
https://github.com/zfsonlinux/zfs/issues/8396
Short story:
When running a ZFS on a Linux 4.19/4.20 NFS server the clients are
occasionally unsuccessful in perfectly normal page-in on mapped files.
Example: executable on NFS mounted filesystem. Some executable-mapped
page is referenced. The page is supposed to be retrieved on demand if
not resident yet. This occasionally fails with recent Linux or ZoL
code.
The semantics of the error are identical to what is legitimately
happening when you have a page fault in a NFS client mapped file after
that file has been unlinked on the server side. Here it is happening
without the unlinking.
I suspect this might be a general Linux mm problem because I
cross-checked with a FreeBSD server with very similar ZFS code.
Although I cannot track when the error started appearing I know it is
about within the last 6 months and I read all commits to ZoL that
manage pages and couldn't see anything suspicious off-hand. On the
other hand the errors do not appear when moving the server side file
tree to ext4fs.
The errors get more frequent with uptime of the server and are not
impressed by drop_caches or by trying to evict ZFS' own caches with
memory pressure.
Details with a line of reasoning why I blame the server and all other
info I am collecting:
https://github.com/zfsonlinux/zfs/issues/8396
Thanks
Martin
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <cracauer@cons.org> http://www.cons.org/cracauer/
reply other threads:[~2019-02-11 16:49 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=20190211162821.GA38018@cons.org \
--to=cracauer@cons.org \
--cc=linux-kernel@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).