Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1237449

Re: NFS / FuseFS Kernel Hangs Bug

From Austin S Hemmelgarn <ahferroin7@gmail.com>
Newsgroups linux.kernel
Subject Re: NFS / FuseFS Kernel Hangs Bug
Date 2015-10-01 16:30 +0200
Message-ID <qeN1U-795-3@gated-at.bofh.it> (permalink)
References <qeLMv-53B-31@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


[Multipart message — attachments visible in raw view] - view raw

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.

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

NFS / FuseFS Kernel Hangs Bug "sascha a." <sascha.arthur@gmail.com> - 2015-10-01 15:10 +0200
  Re: NFS / FuseFS Kernel Hangs Bug Austin S Hemmelgarn <ahferroin7@gmail.com> - 2015-10-01 16:30 +0200
    Re: NFS / FuseFS Kernel Hangs Bug "sascha a." <sascha.arthur@gmail.com> - 2015-10-01 16:50 +0200
      Re: NFS / FuseFS Kernel Hangs Bug Austin S Hemmelgarn <ahferroin7@gmail.com> - 2015-10-01 17:30 +0200

csiph-web