Boot regression caused by commit 6829a048

DISCUSSION Sasha Levin 3 participants 7 messages Jan 6, 2012 – Jan 7, 2012

Subsystems (2)

NFS client NFS server

lore

Share & tools

lore

Sasha Levin

author

2012-01-06 17:33 UTC #0 lore raw

Hi all,

I've noticed a boot regression caused by commit 6829a048 ("NFS: Retry mounting NFSROOT") which has increased boot time by 95 seconds.

The scenario is as follows:
- A virtual guest running under the KVM tool.
- Guest is using kernel automatic IP DHCP configuration ("ip=dhcp").
- Guest is booting from a 9p device (which is not detected as block,
and gets mounted after NFS tries to do its mounts).
- No NFS server at all, no NFS parameters passed to the guest kernel.

Under this scenario, theres an additional 95 second delay before NFS fails and tries to boot using 9p:

[...]

[    6.505269] md: autorun ...
[    6.506954] md: ... autorun DONE.
[  101.522716] VFS: Unable to mount root fs via NFS, trying floppy.
[  101.534499] VFS: Mounted root (9p filesystem) on device 0:18.

[...]

This probably happens since the NFS server isn't configured, so the bootserver is automatically assumed to be the DHCP server, and with the commit above we won't simply fail immediately when the NFS code fails connecting to it.

I'm not quite sure about the correct solution for this. While I can forcefully disable NFS, is it really the right solution? Should we be retrying a NFS server even if one wasn't specifically set?

Thanks.

Signature · 1 line

Sasha.

Trond Myklebust

2012-01-06 18:26 UTC #1 lore raw

Quoted 15 lines · Sasha Levin

Hi all,
I've noticed a boot regression caused by commit 6829a048 ("NFS: Retry mounting NFSROOT") which has increased boot time by 95 seconds.
The scenario is as follows:
- A virtual guest running under the KVM tool.
- Guest is using kernel automatic IP DHCP configuration ("ip=dhcp").
- Guest is booting from a 9p device (which is not detected as block,
and gets mounted after NFS tries to do its mounts).
- No NFS server at all, no NFS parameters passed to the guest kernel.
Under this scenario, theres an additional 95 second delay before NFS fails and tries to boot using 9p:

Quoted 6 lines

[...]

[    6.505269] md: autorun ...
[    6.506954] md: ... autorun DONE.
[  101.522716] VFS: Unable to mount root fs via NFS, trying floppy.
[  101.534499] VFS: Mounted root (9p filesystem) on device 0:18.

[...]

Can't you avoid the whole NFS root mount attempt by setting "root=2:0" directly instead of relying on 'mount_root' to do it for you?

Quoted 8 lines

This probably happens since the NFS server isn't configured, so the bootserver is automatically assumed to be the DHCP server, and with the commit above we won't simply fail immediately when the NFS code fails connecting to it.
I'm not quite sure about the correct solution for this. While I can forcefully disable NFS, is it really the right solution? Should we be retrying a NFS server even if one wasn't specifically set?

One option might be to check the 'root_wait' flag. We could also add nfsroot support for the 'retry=' mount option.

Signature · 6 lines

Trond Myklebust
Linux NFS client maintainer

NetApp
[email protected]
www.netapp.com

Sasha Levin

author

2012-01-06 21:33 UTC #2 lore raw

Quoted 23 lines · Trond Myklebust

Quoted 15 lines · Sasha Levin
Hi all,
I've noticed a boot regression caused by commit 6829a048 ("NFS: Retry mounting NFSROOT") which has increased boot time by 95 seconds.
The scenario is as follows:
- A virtual guest running under the KVM tool.
- Guest is using kernel automatic IP DHCP configuration ("ip=dhcp").
- Guest is booting from a 9p device (which is not detected as block,
and gets mounted after NFS tries to do its mounts).
- No NFS server at all, no NFS parameters passed to the guest kernel.
Under this scenario, theres an additional 95 second delay before NFS fails and tries to boot using 9p:
Quoted 6 lines
[...]
[    6.505269] md: autorun ...
[    6.506954] md: ... autorun DONE.
[  101.522716] VFS: Unable to mount root fs via NFS, trying floppy.
[  101.534499] VFS: Mounted root (9p filesystem) on device 0:18.
[...]

Quoted 2 lines

Can't you avoid the whole NFS root mount attempt by setting "root=2:0" directly instead of relying on 'mount_root' to do it for you?

I am specifying root and root parameters fully:

"root=/dev/root rw rootflags=rw,trans=virtio,version=9p2000.L rootfstype=9p"

Actually, I'm not sure why NFS comes to play at all in this case.

Signature · 1 line

Sasha.

Trond Myklebust

2012-01-06 23:16 UTC #3 lore raw

Quoted 27 lines · Sasha Levin

Quoted 23 lines · Trond Myklebust
Quoted 15 lines · Sasha Levin
Hi all,
I've noticed a boot regression caused by commit 6829a048 ("NFS: Retry mounting NFSROOT") which has increased boot time by 95 seconds.
The scenario is as follows:
- A virtual guest running under the KVM tool.
- Guest is using kernel automatic IP DHCP configuration ("ip=dhcp").
- Guest is booting from a 9p device (which is not detected as block,
and gets mounted after NFS tries to do its mounts).
- No NFS server at all, no NFS parameters passed to the guest kernel.
Under this scenario, theres an additional 95 second delay before NFS fails and tries to boot using 9p:
Quoted 6 lines
[...]
[    6.505269] md: autorun ...
[    6.506954] md: ... autorun DONE.
[  101.522716] VFS: Unable to mount root fs via NFS, trying floppy.
[  101.534499] VFS: Mounted root (9p filesystem) on device 0:18.
[...]
Quoted 2 lines
Can't you avoid the whole NFS root mount attempt by setting "root=2:0" directly instead of relying on 'mount_root' to do it for you?

Quoted 6 lines

I am specifying root and root parameters fully:
"root=/dev/root rw rootflags=rw,trans=virtio,version=9p2000.L rootfstype=9p"
Actually, I'm not sure why NFS comes to play at all in this case.

It's because mount_root() tests MAJOR(ROOT_DEV) only when probing for nfsroot. Since ROOT_DEV is initialised to 0, and root=/dev/root matches nothing in name_to_dev_t(), then you end up matching the nfsroot test.

A simple fix would be either:

A) skip the root=/dev/root.
B) change mount_root to also test MINOR(ROOT_DEV), which should equal 255 if ROOT_DEV==Root_NFS

Signature · 6 lines

Trond Myklebust
Linux NFS client maintainer

NetApp
[email protected]
www.netapp.com

Sasha Levin

author

2012-01-07 08:59 UTC #4 lore raw

Quoted 3 lines · Trond Myklebust

A simple fix would be either:
A) skip the root=/dev/root.

"/dev/root" is actually the name of the 9p device, I can't omit that part since then 9p won't boot.

Quoted 2 lines

B) change mount_root to also test MINOR(ROOT_DEV), which should equal 255 if ROOT_DEV==Root_NFS

I'll simply check if ROOT_DEV==Root_NFS then.

Signature · 1 line

Sasha.

Chuck Lever

2012-01-06 18:29 UTC #5 lore raw

In reply to Sasha Levin

Quoted 22 lines · Sasha Levin

Hi all,
I've noticed a boot regression caused by commit 6829a048 ("NFS: Retry mounting NFSROOT") which has increased boot time by 95 seconds.
The scenario is as follows:
- A virtual guest running under the KVM tool.
- Guest is using kernel automatic IP DHCP configuration ("ip=dhcp").
- Guest is booting from a 9p device (which is not detected as block, and gets mounted after NFS tries to do its mounts).
- No NFS server at all, no NFS parameters passed to the guest kernel.
Under this scenario, theres an additional 95 second delay before NFS fails and tries to boot using 9p:
[...]
[    6.505269] md: autorun ...
[    6.506954] md: ... autorun DONE.
[  101.522716] VFS: Unable to mount root fs via NFS, trying floppy.
[  101.534499] VFS: Mounted root (9p filesystem) on device 0:18.
[...]

Quoted 8 lines

This probably happens since the NFS server isn't configured, so the bootserver is automatically assumed to be the DHCP server, and with the commit above we won't simply fail immediately when the NFS code fails connecting to it.
I'm not quite sure about the correct solution for this. While I can forcefully disable NFS, is it really the right solution? Should we be retrying a NFS server even if one wasn't specifically set?

What DHCP options are passed to the client? You can specify the "nfsrootdebug" boot command line option to explore this a little more.

Typically ip= is used specifically with NFSROOT. You might review Documentation/filesystems/nfs/nfsroot.txt to see if some combination of boot command line options gives more desirable behavior.

Signature · 2 lines

Chuck Lever
chuck[dot]lever[at]oracle[dot]com

Sasha Levin

author

2012-01-06 21:36 UTC #6 lore raw

Quoted 29 lines · Chuck Lever

Quoted 27 lines · Sasha Levin
Hi all,
I've noticed a boot regression caused by commit 6829a048 ("NFS: Retry mounting NFSROOT") which has increased boot time by 95 seconds.
The scenario is as follows:
- A virtual guest running under the KVM tool.
- Guest is using kernel automatic IP DHCP configuration ("ip=dhcp").
- Guest is booting from a 9p device (which is not detected as block, and gets mounted after NFS tries to do its mounts).
- No NFS server at all, no NFS parameters passed to the guest kernel.
Under this scenario, theres an additional 95 second delay before NFS fails and tries to boot using 9p:
[...]
[    6.505269] md: autorun ...
[    6.506954] md: ... autorun DONE.
[  101.522716] VFS: Unable to mount root fs via NFS, trying floppy.
[  101.534499] VFS: Mounted root (9p filesystem) on device 0:18.
[...]
This probably happens since the NFS server isn't configured, so the bootserver is automatically assumed to be the DHCP server, and with the commit above we won't simply fail immediately when the NFS code fails connecting to it.

Quoted 5 lines

Quoted 3 lines
I'm not quite sure about the correct solution for this. While I can forcefully disable NFS, is it really the right solution? Should we be retrying a NFS server even if one wasn't specifically set?
What DHCP options are passed to the client? You can specify the "nfsrootdebug" boot command line option to explore this a little more.

This is what came out:

[    5.220654] NFS: nfs mount opts='vers=2,udp,rsize=4096,wsize=4096,nolock,addr=0.0.0.0'
[    5.226382] NFS:   parsing nfs mount option 'vers=2'
[    5.227707] NFS:   parsing nfs mount option 'udp'
[    5.228781] NFS:   parsing nfs mount option 'rsize=4096'
[    5.230307] NFS:   parsing nfs mount option 'wsize=4096'
[    5.231537] NFS:   parsing nfs mount option 'nolock'
[    5.232834] NFS:   parsing nfs mount option 'addr=0.0.0.0'
[    5.234069] NFS: mount program didn't pass remote address

Quoted 1 line

Typically ip= is used specifically with NFSROOT. You might review Documentation/filesystems/nfs/nfsroot.txt to see if some combination of boot command line options gives more desirable behavior.

Within nfsroot.txt, it says I should specify "root=/dev/nfs" so that nfsroot would be used. Why do we try mounting nfsroot if I specifically specify something else under "root="?

Signature · 1 line

Sasha.