* Re: Re: NFS retry on disconnection
2002-05-13 19:53 ` Ion Badulescu
@ 2002-05-13 21:04 ` Greg Lindahl
0 siblings, 0 replies; 6+ messages in thread
From: Greg Lindahl @ 2002-05-13 21:04 UTC (permalink / raw)
To: nfs
On Mon, May 13, 2002 at 03:53:00PM -0400, Ion Badulescu wrote:
> > Though you didn't answer the question, your advice implies that the Linux
> > NFSv3 filesystem driver retries forever when communication with the NFS
> > server has been lost. If not, please correct us.
>
> The default is 'hard' which will retry forever.
>
> You can mount with '-o soft' which will give you the desired data corruption.
Linux NFS isn't any different from any other OS in this treatment of
"soft" and "hard", although I guess an OS could have a default to
"soft", which would be a bad idea.
"Best practices" is to mount "hard,intr" so the user can interrupt the
process if they wish to... otherwise it will wait until the problem is
fixed. You should also use automounts to ensure that a minimum number
of filesystems are mounted, especially if you have a complicated setup
with many infrequently-used filesystems.
greg
_______________________________________________________________
Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: bandwidth@sourceforge.net
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Re: NFS retry on disconnection
@ 2002-05-14 6:37 Peter Åstrand
2002-05-14 8:16 ` Trond Myklebust
0 siblings, 1 reply; 6+ messages in thread
From: Peter Åstrand @ 2002-05-14 6:37 UTC (permalink / raw)
To: nfs
>Linux NFS isn't any different from any other OS in this treatment of
>"soft" and "hard", although I guess an OS could have a default to
>"soft", which would be a bad idea.
>
>"Best practices" is to mount "hard,intr" so the user can interrupt the
>process if they wish to... otherwise it will wait until the problem is
>fixed. You should also use automounts to ensure that a minimum number
One thing that keeps annoying me is that "intr" only allows interrupting
the file operation when a major timeout happens. I want to be able to
interrupt at any time (as far as I know, Solaris works like this). Any
good reasons for only interrupting at major timeouts?
--
/Peter Åstrand <astrand@lysator.liu.se>
_______________________________________________________________
Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: bandwidth@sourceforge.net
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Re: NFS retry on disconnection
2002-05-14 6:37 Re: NFS retry on disconnection Peter Åstrand
@ 2002-05-14 8:16 ` Trond Myklebust
2002-05-14 8:38 ` Peter Astrand
2002-05-14 22:52 ` Ion Badulescu
0 siblings, 2 replies; 6+ messages in thread
From: Trond Myklebust @ 2002-05-14 8:16 UTC (permalink / raw)
To: Peter Åstrand; +Cc: nfs
>>>>> " " == astrand <Peter> writes:
> One thing that keeps annoying me is that "intr" only allows
> interrupting the file operation when a major timeout happens. I
Nope. Major, minor, it all goes through the same code and both can be
interrupted. What can happen, though, is that one process could
actually be waiting on another process.
If, say, they are both waiting to read data from the same page, then
only one process actually does the RPC call. The VFS/MM layers will
put the other process to sleep in the global function 'lock_page()'.
That unfortunately means that it cannot interrupt, since 'lock_page()'
does not do interruptible sleeps.
Cheers,
Trond
_______________________________________________________________
Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: bandwidth@sourceforge.net
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Re: NFS retry on disconnection
2002-05-14 8:16 ` Trond Myklebust
@ 2002-05-14 8:38 ` Peter Astrand
2002-05-14 9:31 ` Trond Myklebust
2002-05-14 22:52 ` Ion Badulescu
1 sibling, 1 reply; 6+ messages in thread
From: Peter Astrand @ 2002-05-14 8:38 UTC (permalink / raw)
To: nfs
> > One thing that keeps annoying me is that "intr" only allows
> > interrupting the file operation when a major timeout happens. I
>
> Nope. Major, minor, it all goes through the same code and both can be
> interrupted.
Does this mean that the man page nfs(5) is incorrect? It says:
"intr
If an NFS file operation has a major timeout and it is hard mounted, then
allow signals to interupt the file operation and cause it to return EINTR
to the calling program."
> If, say, they are both waiting to read data from the same page, then
> only one process actually does the RPC call. The VFS/MM layers will
> put the other process to sleep in the global function 'lock_page()'.
> That unfortunately means that it cannot interrupt, since 'lock_page()'
> does not do interruptible sleeps.
I see. And this is not possible to change?
--
/Peter Åstrand <astrand@lysator.liu.se>
_______________________________________________________________
Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: bandwidth@sourceforge.net
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Re: NFS retry on disconnection
2002-05-14 8:38 ` Peter Astrand
@ 2002-05-14 9:31 ` Trond Myklebust
0 siblings, 0 replies; 6+ messages in thread
From: Trond Myklebust @ 2002-05-14 9:31 UTC (permalink / raw)
To: Peter Astrand; +Cc: nfs
>>>>> " " == Peter Astrand <astrand@lysator.liu.se> writes:
> Does this mean that the man page nfs(5) is incorrect? It says:
> "intr
> If an NFS file operation has a major timeout and it is hard
> mounted, then allow signals to interupt the file operation and
> cause it to return EINTR to the calling program."
That looks to be incorrect, yes.
>> function 'lock_page()'. That unfortunately means that it
>> cannot interrupt, since 'lock_page()' does not do interruptible
>> sleeps.
> I see. And this is not possible to change?
Not without great effort, and it would demand considerable auditing to
determine exactly where interruptible sleeps make sense.
A better alternative might be to use asynchronous I/O (as in the POSIX
'aio' library functions). There are patches floating around for that
sort of thing.
Cheers,
Trond
_______________________________________________________________
Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: bandwidth@sourceforge.net
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Re: NFS retry on disconnection
2002-05-14 8:16 ` Trond Myklebust
2002-05-14 8:38 ` Peter Astrand
@ 2002-05-14 22:52 ` Ion Badulescu
1 sibling, 0 replies; 6+ messages in thread
From: Ion Badulescu @ 2002-05-14 22:52 UTC (permalink / raw)
To: Trond Myklebust; +Cc: nfs, Peter ?strand
On 14 May 2002 10:16:59 +0200, Trond Myklebust <trond.myklebust@fys.uio.no> wrote:
> Nope. Major, minor, it all goes through the same code and both can be
> interrupted. What can happen, though, is that one process could
> actually be waiting on another process.
What I've noticed is that, more often than not, the hanging processes
end up waiting for rpciod. Sending a SIGKILL to rpciod unhangs those
processes, but unfortunately only root can do that...
Ion
--
It is better to keep your mouth shut and be thought a fool,
than to open it and remove all doubt.
_______________________________________________________________
Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: bandwidth@sourceforge.net
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2002-05-14 22:52 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2002-05-14 6:37 Re: NFS retry on disconnection Peter Åstrand
2002-05-14 8:16 ` Trond Myklebust
2002-05-14 8:38 ` Peter Astrand
2002-05-14 9:31 ` Trond Myklebust
2002-05-14 22:52 ` Ion Badulescu
-- strict thread matches above, loose matches on Subject: below --
2002-05-13 16:17 Bryan Henderson
2002-05-13 19:53 ` Ion Badulescu
2002-05-13 21:04 ` Greg Lindahl
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.