From: bfields@fieldses.org (J. Bruce Fields)
To: Alan Post <adp@prgmr.com>
Cc: "linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>
Subject: Re: User process NFS write hang followed by automount hang requiring reboot
Date: Thu, 30 May 2019 14:39:58 -0400 [thread overview]
Message-ID: <20190530183958.GA23001@fieldses.org> (raw)
In-Reply-To: <20190521192254.GN4158@turtle.email>
On Tue, May 21, 2019 at 01:22:54PM -0600, Alan Post wrote:
> On Tue, May 21, 2019 at 03:46:03PM +0000, Trond Myklebust wrote:
> > > A representative sample of stack traces from hung user-submitted
> > > processes (jobs). The first here is quite a lot more common than
> > > the later two:
> > >
> > > $ sudo cat /proc/197520/stack
> > > [<0>] io_schedule+0x12/0x40
> > > [<0>] nfs_lock_and_join_requests+0x309/0x4c0 [nfs]
> > > [<0>] nfs_updatepage+0x2a2/0x8b0 [nfs]
> > > [<0>] nfs_write_end+0x63/0x4c0 [nfs]
> > > [<0>] generic_perform_write+0x138/0x1b0
> > > [<0>] nfs_file_write+0xdc/0x200 [nfs]
> > > [<0>] new_sync_write+0xfb/0x160
> > > [<0>] vfs_write+0xa5/0x1a0
> > > [<0>] ksys_write+0x4f/0xb0
> > > [<0>] do_syscall_64+0x53/0x100
> > > [<0>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
> > > [<0>] 0xffffffffffffffff
> > >
> >
> > Have you tried upgrading to 4.19.44? There is a fix that went in not
> > too long ago that deals with a request leak that can cause stack traces
> > like the above that wait forever.
> >
>
> That I haven't tried. I gather you're talking about either or both
> of:
>
> 63b0ee126f7e
> be74fddc976e
>
> Which I do see went in after 4.19.24 (which I've tried) but didn't
> get in 4.20.9 (which I've also tried). Let me see about trying the
> 4.19.44 kernel.
>
> > By the way, the above stack trace with "nfs_lock_and_join_requests"
> > usually means that you are using a very small rsize or wsize (less than
> > 4k). Is that the case? If so, you might want to look into just
> > increasing the I/O size.
> >
>
> These exports have rsize and wsize set to 1048576.
Are you getting that from the mount commandline? It could be negotiated
down during mount. I think you can get the negotiated values form the
rsize= and wsize= values on the opts: line in /proc/self/mountstats.
See also /proc/fs/nfsd/max_block_size.
--b.
> That decision was
> before my time, and I'll guess this value was picked to match
> NFSSVC_MAXBLKSIZE.
>
> Thank you for your help,
>
> -A
> --
> Alan Post | Xen VPS hosting for the technically adept
> PO Box 61688 | Sunnyvale, CA 94088-1681 | https://prgmr.com/
> email: adp@prgmr.com
next prev parent reply other threads:[~2019-05-30 18:40 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-20 22:33 User process NFS write hang followed by automount hang requiring reboot Alan Post
2019-05-21 15:46 ` Trond Myklebust
2019-05-21 19:22 ` Alan Post
2019-05-30 18:39 ` J. Bruce Fields [this message]
2019-05-31 0:22 ` Alan Post
2019-05-24 17:31 ` Alan Post
2019-05-24 19:19 ` Trond Myklebust
2019-05-30 0:41 ` Alan Post
2019-05-30 1:09 ` Trond Myklebust
2019-06-04 17:44 ` Alan Post
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=20190530183958.GA23001@fieldses.org \
--to=bfields@fieldses.org \
--cc=adp@prgmr.com \
--cc=linux-nfs@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).