background mounts inconsistent and partly not usable

background mounts inconsistent and partly not usable

[Daniel Goering]

Hi!

I'd like to mount an NFS4 share with the option bg as described in man 5
nfs. But all mounts are carried out in the foreground and time out after
2 minutes [and the client is blocked e.g. during boot for the entire
time] instead of trying in the background for about 1 week until the
server is back up.

When I try to mount a share from an unreachable server I get something like

# mount.nfs4 10.1.2.3:/ /mnt/ -v -o bg
mount.nfs4: text-based options: 'bg,clientaddr=xxx,addr=10.1.2.3'
mount.nfs4: mount(2): Input/output error
mount.nfs4: mount system call failed

I tracked this down to utils/mount/stropts.c, where the function
nfs_is_permanent_error maps EIO to an permanent error and prevents the
mount from backgrounding.

I changed utils/mount/mount.c to use the old non string mount, in order
to compare the results

--- mount.c.bak	2010-02-16 18:06:09.000000000 +0100
+++ mount.c	2010-02-16 18:06:12.000000000 +0100
@@ -175,7 +175,7 @@
 	if (nfs_mount_data_version > NFS_MOUNT_VERSION)
 		nfs_mount_data_version = NFS_MOUNT_VERSION;
 	else
-		if (kernel_version > MAKE_VERSION(2, 6, 22))
+		if (kernel_version > MAKE_VERSION(3, 6, 22))
 			string++;
 }


and I get this result, if there is no route to the host
# mount.nfs4 10.1.2.3:/ /mnt/ -v -o bg
mount.nfs4: pinging: prog 100003 vers 4 prot tcp port 2049
mount.nfs4: Unable to connect to 10.1.2.3:2049, errno 113 (No route to host)

instead of waiting 2 minutes this call immediately returns. If there is
just no answer from the host instead of a "no route to host" message, I get
# mount.nfs4 10.1.2.3:/ /mnt/ -v -o bg
mount.nfs4: pinging: prog 100003 vers 4 prot tcp port 2049
mount.nfs4: Unable to connect to 10.1.2.3:2049, errno 110 (Connection
timed out)

mount.nfs4: backgrounding "10.1.2.3:/"

Both calls to the old non-string mount are significantly faster, and the
last one even backgrounds, while the string mount gives EIO in both
cases and never backgrounds.

I'd like to use the bg option to be able to boot the clients
simultaneously with the servers and the clients should just mount the
share, as soon as it becomes available.
Currently this is never possible with any machine running a kernel newer
than 2.6.22, as they will all die of the EIO error. Even for an older
Kernel this is only possible, if the server is already booting and can
answer ARP requests, as otherwise the mount will die from the "no route
to host" message.
I'd prefer if mount tried to find a route for about one week, to have
some time to turn on the servers separately [so they can spin up their
RAIDs sequentially instead of burning the fuse by consuming lots of
power during simultaneous spin up], but may be there are good reasons to
have it differently.
Nevertheless I think that it should at least be possible to mount shares
in the background after a timeout for systems with recent kernels using
string mount.

I observed the given problems with the following systems:
Gentoo	Kernel 2.6.31.4 	nfs-utils	1.1.4
Gentoo	Kernel 2.6.31.4 	nfs-utils	1.2.1
Fedora 12	Kernel 2.6.31.12	nfs-utils 	1.2.1

For now I'll probably just patch nfs_is_permanent_error on all my
systems to just map everything to temporary, but I hope there is a more
robust solution, that will allow fast feedback on problems and still
support background mounts.


Cheers
	Daniel

Re: background mounts inconsistent and partly not usable

[Chuck Lever]

Thanks for the report, I'll look into it.

On 02/16/2010 12:52 PM, Daniel Goering wrote:
> Hi!
>
> I'd like to mount an NFS4 share with the option bg as described in man 5
> nfs. But all mounts are carried out in the foreground and time out after
> 2 minutes [and the client is blocked e.g. during boot for the entire
> time] instead of trying in the background for about 1 week until the
> server is back up.
>
> When I try to mount a share from an unreachable server I get something like
>
> # mount.nfs4 10.1.2.3:/ /mnt/ -v -o bg
> mount.nfs4: text-based options: 'bg,clientaddr=xxx,addr=10.1.2.3'
> mount.nfs4: mount(2): Input/output error
> mount.nfs4: mount system call failed
>
> I tracked this down to utils/mount/stropts.c, where the function
> nfs_is_permanent_error maps EIO to an permanent error and prevents the
> mount from backgrounding.
>
> I changed utils/mount/mount.c to use the old non string mount, in order
> to compare the results
>
> --- mount.c.bak	2010-02-16 18:06:09.000000000 +0100
> +++ mount.c	2010-02-16 18:06:12.000000000 +0100
> @@ -175,7 +175,7 @@
>   	if (nfs_mount_data_version>  NFS_MOUNT_VERSION)
>   		nfs_mount_data_version = NFS_MOUNT_VERSION;
>   	else
> -		if (kernel_version>  MAKE_VERSION(2, 6, 22))
> +		if (kernel_version>  MAKE_VERSION(3, 6, 22))
>   			string++;
>   }
>
>
> and I get this result, if there is no route to the host
> # mount.nfs4 10.1.2.3:/ /mnt/ -v -o bg
> mount.nfs4: pinging: prog 100003 vers 4 prot tcp port 2049
> mount.nfs4: Unable to connect to 10.1.2.3:2049, errno 113 (No route to host)
>
> instead of waiting 2 minutes this call immediately returns. If there is
> just no answer from the host instead of a "no route to host" message, I get
> # mount.nfs4 10.1.2.3:/ /mnt/ -v -o bg
> mount.nfs4: pinging: prog 100003 vers 4 prot tcp port 2049
> mount.nfs4: Unable to connect to 10.1.2.3:2049, errno 110 (Connection
> timed out)
>
> mount.nfs4: backgrounding "10.1.2.3:/"
>
> Both calls to the old non-string mount are significantly faster, and the
> last one even backgrounds, while the string mount gives EIO in both
> cases and never backgrounds.
>
> I'd like to use the bg option to be able to boot the clients
> simultaneously with the servers and the clients should just mount the
> share, as soon as it becomes available.
> Currently this is never possible with any machine running a kernel newer
> than 2.6.22, as they will all die of the EIO error. Even for an older
> Kernel this is only possible, if the server is already booting and can
> answer ARP requests, as otherwise the mount will die from the "no route
> to host" message.
> I'd prefer if mount tried to find a route for about one week, to have
> some time to turn on the servers separately [so they can spin up their
> RAIDs sequentially instead of burning the fuse by consuming lots of
> power during simultaneous spin up], but may be there are good reasons to
> have it differently.
> Nevertheless I think that it should at least be possible to mount shares
> in the background after a timeout for systems with recent kernels using
> string mount.
>
> I observed the given problems with the following systems:
> Gentoo	Kernel 2.6.31.4 	nfs-utils	1.1.4
> Gentoo	Kernel 2.6.31.4 	nfs-utils	1.2.1
> Fedora 12	Kernel 2.6.31.12	nfs-utils 	1.2.1
>
> For now I'll probably just patch nfs_is_permanent_error on all my
> systems to just map everything to temporary, but I hope there is a more
> robust solution, that will allow fast feedback on problems and still
> support background mounts.
>
>
> Cheers
> 	Daniel
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


-- 
chuck[dot]lever[at]oracle[dot]com

Re: background mounts inconsistent and partly not usable

[Chuck Lever]

Hi Daniel-

On 02/16/2010 12:52 PM, Daniel Goering wrote:
> Hi!
>
> I'd like to mount an NFS4 share with the option bg as described in man 5
> nfs. But all mounts are carried out in the foreground and time out after
> 2 minutes [and the client is blocked e.g. during boot for the entire
> time] instead of trying in the background for about 1 week until the
> server is back up.
>
> When I try to mount a share from an unreachable server I get something like
>
> # mount.nfs4 10.1.2.3:/ /mnt/ -v -o bg
> mount.nfs4: text-based options: 'bg,clientaddr=xxx,addr=10.1.2.3'
> mount.nfs4: mount(2): Input/output error
> mount.nfs4: mount system call failed
>
> I tracked this down to utils/mount/stropts.c, where the function
> nfs_is_permanent_error maps EIO to an permanent error and prevents the
> mount from backgrounding.
>
> I changed utils/mount/mount.c to use the old non string mount, in order
> to compare the results
>
> --- mount.c.bak	2010-02-16 18:06:09.000000000 +0100
> +++ mount.c	2010-02-16 18:06:12.000000000 +0100
> @@ -175,7 +175,7 @@
>   	if (nfs_mount_data_version>  NFS_MOUNT_VERSION)
>   		nfs_mount_data_version = NFS_MOUNT_VERSION;
>   	else
> -		if (kernel_version>  MAKE_VERSION(2, 6, 22))
> +		if (kernel_version>  MAKE_VERSION(3, 6, 22))
>   			string++;
>   }
>
>
> and I get this result, if there is no route to the host
> # mount.nfs4 10.1.2.3:/ /mnt/ -v -o bg
> mount.nfs4: pinging: prog 100003 vers 4 prot tcp port 2049
> mount.nfs4: Unable to connect to 10.1.2.3:2049, errno 113 (No route to host)
>
> instead of waiting 2 minutes this call immediately returns. If there is
> just no answer from the host instead of a "no route to host" message, I get
> # mount.nfs4 10.1.2.3:/ /mnt/ -v -o bg
> mount.nfs4: pinging: prog 100003 vers 4 prot tcp port 2049
> mount.nfs4: Unable to connect to 10.1.2.3:2049, errno 110 (Connection
> timed out)
>
> mount.nfs4: backgrounding "10.1.2.3:/"
>
> Both calls to the old non-string mount are significantly faster, and the
> last one even backgrounds, while the string mount gives EIO in both
> cases and never backgrounds.
>
> I'd like to use the bg option to be able to boot the clients
> simultaneously with the servers and the clients should just mount the
> share, as soon as it becomes available.
> Currently this is never possible with any machine running a kernel newer
> than 2.6.22, as they will all die of the EIO error. Even for an older
> Kernel this is only possible, if the server is already booting and can
> answer ARP requests, as otherwise the mount will die from the "no route
> to host" message.

FWIW, some of this is addressed in the 2.6.33 kernel.  EIO is the wrong 
error for the kernel to return in this case.  With 2.6.33, string-based 
NFSv4 mounts behave like legacy mounts; no route to host causes 
immediate failure, no answer causes mount to background.

There's still a question of whether "no route to host" should fail 
immediately, or should background.  We can add EHOSTUNREACH to 
nfs_is_permanent_error(), but that will make foreground mounts hang for 
2 minutes if the admin misspells the server name.  A minor point, perhaps.

Anyone else have opinions about this?

> I'd prefer if mount tried to find a route for about one week, to have
> some time to turn on the servers separately [so they can spin up their
> RAIDs sequentially instead of burning the fuse by consuming lots of
> power during simultaneous spin up], but may be there are good reasons to
> have it differently.
> Nevertheless I think that it should at least be possible to mount shares
> in the background after a timeout for systems with recent kernels using
> string mount.
>
> I observed the given problems with the following systems:
> Gentoo	Kernel 2.6.31.4 	nfs-utils	1.1.4
> Gentoo	Kernel 2.6.31.4 	nfs-utils	1.2.1
> Fedora 12	Kernel 2.6.31.12	nfs-utils 	1.2.1
>
> For now I'll probably just patch nfs_is_permanent_error on all my
> systems to just map everything to temporary, but I hope there is a more
> robust solution, that will allow fast feedback on problems and still
> support background mounts.
>
>
> Cheers
> 	Daniel
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


-- 
chuck[dot]lever[at]oracle[dot]com