From: Austin S Hemmelgarn <ahferroin7@gmail.com>
To: "sascha a." <sascha.arthur@gmail.com>, linux-kernel@vger.kernel.org
Subject: Re: NFS / FuseFS Kernel Hangs Bug
Date: Thu, 1 Oct 2015 10:24:18 -0400 [thread overview]
Message-ID: <560D4212.3010101@gmail.com> (raw)
In-Reply-To: <CAK_92-ECoKWOPJXbT=BNcXhd5aVq77rWOciKfKf6a-LYTFbDqg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1837 bytes --]
On 2015-10-01 09:06, sascha a. wrote:
> Hello,
>
>
> I want to report a Bug with NFS / FuseFS.
>
> Theres trouble with mounting a NFS FS with FuseFS, if the NFS Server
> is slowly responding.
>
> The problem occurs, if you mount a NFS FS with FuseFS driver for
> example with this command:
>
> mount -t nfs -o vers=3,nfsvers=3,hard,intr,tcp server /dest
>
> Working on this nfs overlay works like a charm, as long as the NFS
> Server is not under heavy load. If it gets under HEAVY load from time
> to time the kernel hangs (which should in my opinion never ever
> occur).
OK, before I start on an explanation of why what is happening is
happening, I should note that unless you're using some special FUSE
driver instead of the regular NFS tools, you're not using FUSE to mount
the NFS share, you're using a regular kernel driver.
Now, on to the explanation:
This behavior is expected and unavoidable for any network filesystem
under the described conditions. Sync (or any other command that causes
access to the filesystem that isn't served by the local cache) requires
sending a command to the server. Sync in particular is _synchronous_
(and it should be, otherwise you break the implied data safety from
using it), which means that it will wait until it gets a reply from the
server before it returns, which means that if the server is heavily
loaded (or just ridiculously slow), it will be a while before it
returns. On top of this, depending on how the server is caching data,
it may take a long time to return even on a really fast server with no
other load.
The stacktrace you posted indicates simply that the kernel noticed that
'sync' was in an I/O sleep state (the 'D state' it refers to) for more
than 120 seconds, which is the default detection timeout for this.
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3019 bytes --]
next prev parent reply other threads:[~2015-10-01 14:25 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-01 13:06 NFS / FuseFS Kernel Hangs Bug sascha a.
2015-10-01 14:24 ` Austin S Hemmelgarn [this message]
2015-10-01 14:45 ` sascha a.
2015-10-01 15:25 ` Austin S Hemmelgarn
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=560D4212.3010101@gmail.com \
--to=ahferroin7@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=sascha.arthur@gmail.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.