Hi. We are using unfsd to provide "personal" mounts in a thin client
environment, based on NFSv3 over TCP over SSH. This works fairly good, but
we would like a little shorter timeout when the server doesn't respond
(such as when the user has disabled file sharing and thus stopped unfsd).
Currently, we are mounting with:
rw,noexec,nosuid,nodev,port=XXXX,mountport=XXXX,mountvers=3,nfsvers=3,nolock,fg,soft,intr,tcp,actimeo=2,addr=127.0.0.1
The important options wrt timeout here is:
fg,soft,intr,tcp
So, we are not using timeo or retrans at all. The result is timeouts
varying between 3 and 180 seconds. The worst case seems to be when doing a
"kill -STOP" on unfsd (thus, simply not respond, in contrast to respond
with EOF or similiar).
My questions are:
* How can we lower the timeouts? To me, it seems like the hardcoded
maximum timeout of 60 seconds is a bit of a problem. How about
introducing an option for changing this?
If we start using, say, retrans=1, does this mean that applications can
recieve EIO after as little as 1 second?
* Is it true that all the "-f" option to umount does is skip trying
MOUNTPROC_UMNT?
* About "intr": The man page says "If an NFS file operation has a major
timeout and it is hard mounted". Does "intr" affect soft mounts in any
way, or is it better to remove it?
Regards,
--
Peter ?strand ThinLinc Chief Developer
Cendio http://www.cendio.se
Teknikringen 3
583 30 Link?ping Phone: +46-13-21 46 00
On Wed, 2006-03-29 at 09:44 +0200, Peter =C3=85strand wrote:
> Hi. We are using unfsd to provide "personal" mounts in a thin client=20
> environment, based on NFSv3 over TCP over SSH. This works fairly good, bu=
t=20
> we would like a little shorter timeout when the server doesn't respond=20
> (such as when the user has disabled file sharing and thus stopped unfsd).=
=20
> Currently, we are mounting with:
>=20
> rw,noexec,nosuid,nodev,port=3DXXXX,mountport=3DXXXX,mountvers=3D3,nfsvers=
=3D3,nolock,fg,soft,intr,tcp,actimeo=3D2,addr=3D127.0.0.1
>=20
> The important options wrt timeout here is:
>=20
> fg,soft,intr,tcp
>=20
> So, we are not using timeo or retrans at all. The result is timeouts=20
> varying between 3 and 180 seconds. The worst case seems to be when doing =
a=20
> "kill -STOP" on unfsd (thus, simply not respond, in contrast to respond=20
> with EOF or similiar).
>=20
> My questions are:
>=20
> * How can we lower the timeouts? To me, it seems like the hardcoded
> maximum timeout of 60 seconds is a bit of a problem. How about
> introducing an option for changing this?
The maximum timeout for TCP is 600 seconds, i.e. 10 minutes.
> If we start using, say, retrans=3D1, does this mean that applications =
can
> recieve EIO after as little as 1 second?
No. "timeo" controls the timeout value. "retrans" controls the number of
retransmissions before a major timeout is declared.
> * Is it true that all the "-f" option to umount does is skip trying
> MOUNTPROC_UMNT?
No. '-f' causes all pending RPC calls to be cancelled (and return -EIO).
> * About "intr": The man page says "If an NFS file operation has a major
> timeout and it is hard mounted". Does "intr" affect soft mounts in any
> way, or is it better to remove it?
Intr changes the set of signals that are able to interrupt an RPC call.
It has nothing to do with "soft".
Cheers,
Trond
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On Wed, 29 Mar 2006, Trond Myklebust wrote:
> On Wed, 2006-03-29 at 09:44 +0200, Peter ?strand wrote:
>> Hi. We are using unfsd to provide "personal" mounts in a thin client
>> environment, based on NFSv3 over TCP over SSH. This works fairly good, but
>> we would like a little shorter timeout when the server doesn't respond
>> * How can we lower the timeouts? To me, it seems like the hardcoded
>> maximum timeout of 60 seconds is a bit of a problem. How about
>> introducing an option for changing this?
>
> The maximum timeout for TCP is 600 seconds, i.e. 10 minutes.
Does this mean that the manpage statement "The maximum timeout is always
60 seconds." is incorrect?
>> If we start using, say, retrans=1, does this mean that applications can
>> recieve EIO after as little as 1 second?
>
> No. "timeo" controls the timeout value. "retrans" controls the number of
> retransmissions before a major timeout is declared.
Yes, but the manpage states that EIO is reported when a major timeout
occurs. So, the time until EIO must be influenced by "retrans", right?
>> * Is it true that all the "-f" option to umount does is skip trying
>> MOUNTPROC_UMNT?
>
> No. '-f' causes all pending RPC calls to be cancelled (and return -EIO).
Is MOUNTPROC_UMNT tried even when -f is specified?
>> * About "intr": The man page says "If an NFS file operation has a major
>> timeout and it is hard mounted". Does "intr" affect soft mounts in any
>> way, or is it better to remove it?
>
> Intr changes the set of signals that are able to interrupt an RPC call.
> It has nothing to do with "soft".
That is - it has no effect when "soft" is used?
I'm still eager to hear some ideas on how the timeouts can be lowered.
Regards,
--
Peter ?strand ThinLinc Chief Developer
Cendio http://www.cendio.se
Teknikringen 3
583 30 Link?ping Phone: +46-13-21 46 00
On Wed, 2006-03-29 at 16:33 +0200, Peter =C3=85strand wrote:
> > The maximum timeout for TCP is 600 seconds, i.e. 10 minutes.
>=20
> Does this mean that the manpage statement "The maximum timeout is always=20
> 60 seconds." is incorrect?
Yes.
> >> If we start using, say, retrans=3D1, does this mean that applicatio=
ns can
> >> recieve EIO after as little as 1 second?
> >
> > No. "timeo" controls the timeout value. "retrans" controls the number o=
f
> > retransmissions before a major timeout is declared.
>=20
> Yes, but the manpage states that EIO is reported when a major timeout=20
> occurs. So, the time until EIO must be influenced by "retrans", right?
It is influenced by _both_. timeo sets the timeout value for a single
retransmission. retrans sets the number of retransmissions in a major
timeout.
> >> * Is it true that all the "-f" option to umount does is skip trying
> >> MOUNTPROC_UMNT?
> >
> > No. '-f' causes all pending RPC calls to be cancelled (and return -EIO)=
.
>=20
> Is MOUNTPROC_UMNT tried even when -f is specified?
I believe so.
> >> * About "intr": The man page says "If an NFS file operation has a majo=
r
> >> timeout and it is hard mounted". Does "intr" affect soft mounts in =
any
> >> way, or is it better to remove it?
> >
> > Intr changes the set of signals that are able to interrupt an RPC call.
> > It has nothing to do with "soft".
>=20
> That is - it has no effect when "soft" is used?
No. I mean that it has the same effect whether you use "soft" or "hard".
Intr controls signals, not timeouts.
Cheers,
Trond
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On Wed, 29 Mar 2006, Trond Myklebust wrote:
>>> The maximum timeout for TCP is 600 seconds, i.e. 10 minutes.
>>
>> Does this mean that the manpage statement "The maximum timeout is always
>> 60 seconds." is incorrect?
>
> Yes.
Let's fix this, then. What about this patch, against
util-linux-2.13-pre7 ?:
--- ./mount/nfs.5.org 2006-03-29 20:54:59.000000000 +0200
+++ ./mount/nfs.5 2006-03-29 20:57:35.000000000 +0200
@@ -43,12 +43,12 @@
first retransmission after an RPC timeout.
The default value is 7 tenths of a second. After the first timeout,
the timeout is doubled after each successive timeout until a maximum
-timeout of 60 seconds is reached or the enough retransmissions
+timeout is reached or the enough retransmissions
have occured to cause a major timeout. Then, if the filesystem
is hard mounted, each new timeout cascade restarts at twice the
initial value of the previous cascade, again doubling at each
-retransmission. The maximum timeout is always 60 seconds.
-Better overall performance may be achieved by increasing the
+retransmission. The maximum timeout is 60 seconds for UDP and 600
+seconds for TCP. Better overall performance may be achieved by increasing
the
timeout when mounting on a busy network, to a slow server, or through
several routers or gateways.
.TP 1.5i
>>>> If we start using, say, retrans=1, does this mean that applications can
>>>> recieve EIO after as little as 1 second?
>>>
>>> No. "timeo" controls the timeout value. "retrans" controls the number of
>>> retransmissions before a major timeout is declared.
>>
>> Yes, but the manpage states that EIO is reported when a major timeout
>> occurs. So, the time until EIO must be influenced by "retrans", right?
>
> It is influenced by _both_. timeo sets the timeout value for a single
> retransmission. retrans sets the number of retransmissions in a major
> timeout.
Ok, so with the default values of timeo=7 and retrans=3, the first major
timeout will occur after 0.7 + 1.4 + 2.8 = 4.9 seconds? And with soft
mounts, this should return EIO to the application?
In that case, how is it possible that I experience timeouts of 180
seconds?!?
>>>> * Is it true that all the "-f" option to umount does is skip trying
>>>> MOUNTPROC_UMNT?
>>>
>>> No. '-f' causes all pending RPC calls to be cancelled (and return -EIO).
>>
>> Is MOUNTPROC_UMNT tried even when -f is specified?
>
> I believe so.
You are right. I've checked the source now. umount always calls
MOUNTPROC_UMNT, using a hardcoded timeout of 20 seconds. I'm including a
patch below that adds an option for controlling this timeout. Comments?
(mount uses a hardcoded timeout of 20 seconds as well in fg mode, even the
manpage says the retry parameter is valid both for fg and bg mode. I'm not
sure if it's the doc or the source that's incorrect. In any case, I think
it's sad that the retry parameter uses *minutes* rather than seconds. Hard
to fix, without breaking backwards compatibility.)
>>>> * About "intr": The man page says "If an NFS file operation has a major
>>>> timeout and it is hard mounted". Does "intr" affect soft mounts in any
>>>> way, or is it better to remove it?
>>>
>>> Intr changes the set of signals that are able to interrupt an RPC call.
>>> It has nothing to do with "soft".
>>
>> That is - it has no effect when "soft" is used?
>
> No. I mean that it has the same effect whether you use "soft" or "hard".
> Intr controls signals, not timeouts.
Then again the man page wording is strange:
"If an NFS file operation has a major timeout and it is hard mounted,"
Shouldn't this read:
"If an NFS file operation has a major timeout,"
?
Regards,
Peter ?strand
Patch that adds a timeout option to umount:
diff -bur util-linux-2.13-pre7.org/mount/umount.8 util-linux-2.13-pre7/mount/umount.8
--- util-linux-2.13-pre7.org/mount/umount.8 2004-11-10 20:49:37.000000000 +0100
+++ util-linux-2.13-pre7/mount/umount.8 2006-03-29 22:13:05.000000000 +0200
@@ -111,6 +111,9 @@
and cleanup all references to the filesystem as soon as it is not busy
anymore.
(Requires kernel 2.4.11 or later.)
+.TP
+.BI \-T " timeout"
+Indicates the timeout to use for NFS operations.
.SH "THE LOOP DEVICE"
The
diff -bur util-linux-2.13-pre7.org/mount/umount.c util-linux-2.13-pre7/mount/umount.c
--- util-linux-2.13-pre7.org/mount/umount.c 2005-09-23 21:55:55.000000000 +0200
+++ util-linux-2.13-pre7/mount/umount.c 2006-03-29 21:48:21.000000000 +0200
@@ -88,6 +88,9 @@
/* True if ruid != euid. */
int suid = 0;
+/* Timeout for NFS operations */
+int timeout = 20;
+
/*
* check_special_umountprog()
* If there is a special umount program for this type, exec it.
@@ -201,7 +204,7 @@
saddr.sin_family = AF_INET;
saddr.sin_port = htons(port);
- pertry.tv_sec = 3;
+ pertry.tv_sec = timeout;
pertry.tv_usec = 0;
if (opts && (p = strstr(opts, "tcp"))) {
/* possibly: make sure option is not "notcp"
@@ -219,7 +222,7 @@
}
}
clp->cl_auth = authunix_create_default();
- try.tv_sec = 20;
+ try.tv_sec = timeout;
try.tv_usec = 0;
clnt_stat = clnt_call(clp, MOUNTPROC_UMNT,
(xdrproc_t) xdr_dir, dirname,
@@ -493,8 +496,8 @@
usage (FILE *fp, int n)
{
fprintf (fp, _("Usage: umount [-hV]\n"
- " umount -a [-f] [-r] [-n] [-v] [-t vfstypes] [-O opts]\n"
- " umount [-f] [-r] [-n] [-v] special | node...\n"));
+ " umount -a [-f] [-r] [-n] [-v] [-T timeout] [-t vfstypes] [-O opts]\n"
+ " umount [-f] [-r] [-n] [-v] [-T timeout] special | node...\n"));
exit (n);
}
@@ -659,7 +662,7 @@
umask(022);
- while ((c = getopt_long (argc, argv, "adfhlnrit:O:vV",
+ while ((c = getopt_long (argc, argv, "adfhlnrit:T:O:vV",
longopts, NULL)) != -1)
switch (c) {
case 'a': /* umount everything */
@@ -696,6 +699,9 @@
case 't': /* specify file system type */
types = optarg;
break;
+ case 'T': /* timeout */
+ timeout = atoi(optarg);
+ break;
case 'i':
external_allowed = 0;
break;
--
Peter ?strand ThinLinc Chief Developer
Cendio http://www.cendio.se
Teknikringen 3
583 30 Link?ping Phone: +46-13-21 46 00
On Wed, 2006-03-29 at 22:24 +0200, Peter =C3=85strand wrote:
> On Wed, 29 Mar 2006, Trond Myklebust wrote:
>=20
> >>> The maximum timeout for TCP is 600 seconds, i.e. 10 minutes.
> >>
> >> Does this mean that the manpage statement "The maximum timeout is alwa=
ys
> >> 60 seconds." is incorrect?
> >
> > Yes.
>=20
> Let's fix this, then. What about this patch, against=20
> util-linux-2.13-pre7 ?:
>=20
> --- ./mount/nfs.5.org 2006-03-29 20:54:59.000000000 +0200
> +++ ./mount/nfs.5 2006-03-29 20:57:35.000000000 +0200
> @@ -43,12 +43,12 @@
> first retransmission after an RPC timeout.
> The default value is 7 tenths of a second. After the first timeout,
> the timeout is doubled after each successive timeout until a maximum
> -timeout of 60 seconds is reached or the enough retransmissions
> +timeout is reached or the enough retransmissions
> have occured to cause a major timeout. Then, if the filesystem
> is hard mounted, each new timeout cascade restarts at twice the
> initial value of the previous cascade, again doubling at each
> -retransmission. The maximum timeout is always 60 seconds.
> -Better overall performance may be achieved by increasing the
> +retransmission. The maximum timeout is 60 seconds for UDP and 600
> +seconds for TCP. Better overall performance may be achieved by increasin=
g=20
> the
> timeout when mounting on a busy network, to a slow server, or through
> several routers or gateways.
> .TP 1.5i
Yeah... Except I'm not sure we should keep the stuff about 'better
overall performance...'. There are sections in the NFS-HOWTO that do a
better job of describing the effect of these options.
> >>>> If we start using, say, retrans=3D1, does this mean that applicat=
ions can
> >>>> recieve EIO after as little as 1 second?
> >>>
> >>> No. "timeo" controls the timeout value. "retrans" controls the number=
of
> >>> retransmissions before a major timeout is declared.
> >>
> >> Yes, but the manpage states that EIO is reported when a major timeout
> >> occurs. So, the time until EIO must be influenced by "retrans", right?
> >
> > It is influenced by _both_. timeo sets the timeout value for a single
> > retransmission. retrans sets the number of retransmissions in a major
> > timeout.
>=20
> Ok, so with the default values of timeo=3D7 and retrans=3D3, the first ma=
jor=20
> timeout will occur after 0.7 + 1.4 + 2.8 =3D 4.9 seconds? And with soft=20
> mounts, this should return EIO to the application?
>=20
> In that case, how is it possible that I experience timeouts of 180=20
> seconds?!?
...because default retransmission timeout value for tcp is timeo=3D60.
Unlike UDP, TCP offers reliable transport, so the only times we should
need to time out and retransmit is if the server is seriously out of
resources and has to drop the request (in which case, we are better off
delaying for a longer period in order to allow the server to recover).
> >>>> * About "intr": The man page says "If an NFS file operation has a ma=
jor
> >>>> timeout and it is hard mounted". Does "intr" affect soft mounts i=
n any
> >>>> way, or is it better to remove it?
> >>>
> >>> Intr changes the set of signals that are able to interrupt an RPC cal=
l.
> >>> It has nothing to do with "soft".
> >>
> >> That is - it has no effect when "soft" is used?
> >
> > No. I mean that it has the same effect whether you use "soft" or "hard"=
.
> > Intr controls signals, not timeouts.
>=20
> Then again the man page wording is strange:
>=20
> "If an NFS file operation has a major timeout and it is hard mounted,"
>=20
> Shouldn't this read:
>=20
> "If an NFS file operation has a major timeout,"
It shouldn't mention major timeouts at all. The Solaris manpage
documents 'intr' as
intr | nointr
Allow (do not allow) keyboard interrupts to kill
a process that is hung while waiting for a
response on a hard-mounted file system. The
default is intr, which makes it possible for
clients to interrupt applications that may be
waiting for a remote mount.
which is pretty much what we aim to do too.
Cheers,
Trond
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On Wed, 2006-03-29 at 15:52 -0500, Trond Myklebust wrote:
> It shouldn't mention major timeouts at all. The Solaris manpage
> documents 'intr' as
>
> intr | nointr
> Allow (do not allow) keyboard interrupts to kill
> a process that is hung while waiting for a
> response on a hard-mounted file system. The
> default is intr, which makes it possible for
> clients to interrupt applications that may be
> waiting for a remote mount.
>
> which is pretty much what we aim to do too.
Sorry... The above thing mentions 'hard-mounted' too. As I said, we
don't distinguish between hard and soft mounts when it comes to allowing
clients to interrupt.
Cheers,
Trond
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On Wed, 29 Mar 2006, Trond Myklebust wrote:
>>>>> The maximum timeout for TCP is 600 seconds, i.e. 10 minutes.
>>>>
>>>> Does this mean that the manpage statement "The maximum timeout is always
>>>> 60 seconds." is incorrect?
>> -Better overall performance may be achieved by increasing the
>> +retransmission. The maximum timeout is 60 seconds for UDP and 600
>> +seconds for TCP. Better overall performance may be achieved by increasing
>> the
>> timeout when mounting on a busy network, to a slow server, or through
>> several routers or gateways.
>> .TP 1.5i
>
> Yeah... Except I'm not sure we should keep the stuff about 'better
> overall performance...'. There are sections in the NFS-HOWTO that do a
> better job of describing the effect of these options.
I've made a new patch, see below.
>> Ok, so with the default values of timeo=7 and retrans=3, the first major
>> timeout will occur after 0.7 + 1.4 + 2.8 = 4.9 seconds? And with soft
>> mounts, this should return EIO to the application?
>>
>> In that case, how is it possible that I experience timeouts of 180
>> seconds?!?
>
> ...because default retransmission timeout value for tcp is timeo=60.
Don't you mean 600? 60 would give a timout of 6 + 12 + 24 = 42 seconds.
> Unlike UDP, TCP offers reliable transport, so the only times we should
> need to time out and retransmit is if the server is seriously out of
> resources and has to drop the request (in which case, we are better off
> delaying for a longer period in order to allow the server to recover).
With our thin clients, the most common case is that the client has
disconnected (thus, the server is no longer running), Or, the user might
have reconnected with NFS exports disabled, perhaps from a platform
without NFS export support.
We want something like 30 seconds of timeout. So, I guess we should aim
for timeo=40.
Here's the new man page patch. Should it be sent to Adrian Bunk?
diff -bur util-linux-2.13-pre7.org/mount/nfs.5 util-linux-2.13-pre7/mount/nfs.5
--- util-linux-2.13-pre7.org/mount/nfs.5 2002-06-27 23:31:33.000000000 +0200
+++ util-linux-2.13-pre7/mount/nfs.5 2006-03-30 15:04:45.000000000 +0200
@@ -39,18 +39,15 @@
.IR wsize=8192 .)
.TP 1.5i
.I timeo=n
-The value in tenths of a second before sending the
-first retransmission after an RPC timeout.
-The default value is 7 tenths of a second. After the first timeout,
-the timeout is doubled after each successive timeout until a maximum
-timeout of 60 seconds is reached or the enough retransmissions
-have occured to cause a major timeout. Then, if the filesystem
-is hard mounted, each new timeout cascade restarts at twice the
-initial value of the previous cascade, again doubling at each
-retransmission. The maximum timeout is always 60 seconds.
-Better overall performance may be achieved by increasing the
-timeout when mounting on a busy network, to a slow server, or through
-several routers or gateways.
+The value in tenths of a second before sending the first
+retransmission after an RPC timeout. The default value is 7 for UDP
+and 600 for TCP. After the first timeout, the timeout is doubled
+after each successive timeout until a maximum timeout is reached or
+the enough retransmissions have occured to cause a major timeout.
+Then, if the filesystem is hard mounted, each new timeout cascade
+restarts at twice the initial value of the previous cascade, again
+doubling at each retransmission. The maximum timeout is 60 seconds
+for UDP and 600 seconds for TCP.
.TP 1.5i
.I retrans=n
The number of minor timeouts and retransmissions that must occur before
@@ -175,8 +172,7 @@
This is the default.
.TP 1.5i
.I 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
+Allow signals to interupt the file operation and cause it to
return EINTR to the calling program. The default is to not
allow file operations to be interrupted.
.TP 1.5i
Regards,
--
Peter ?strand ThinLinc Chief Developer
Cendio http://www.cendio.se
Teknikringen 3
583 30 Link?ping Phone: +46-13-21 46 00