All of lore.kernel.org
 help / color / mirror / Atom feed
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 --]

  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.