Boot regression caused by commit 6829a048

Boot regression caused by commit 6829a048

[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.

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.

-- 

Sasha.

Re: Boot regression caused by commit 6829a048

[Trond Myklebust]

On Fri, 2012-01-06 at 19:32 +0200, Sasha Levin wrote: 
> 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.
> [...]

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?

> 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.

-- 
Trond Myklebust
Linux NFS client maintainer

NetApp
Trond.Myklebust@netapp.com
www.netapp.com

Re: Boot regression caused by commit 6829a048

[Sasha Levin]

On Fri, 2012-01-06 at 13:26 -0500, Trond Myklebust wrote:
> On Fri, 2012-01-06 at 19:32 +0200, Sasha Levin wrote: 
> > 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.
> > [...]
> 
> 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.

-- 

Sasha.

Re: Boot regression caused by commit 6829a048

[Trond Myklebust]

On Sat, 2012-01-07 at 01:32 +0200, Sasha Levin wrote: 
> On Fri, 2012-01-06 at 13:26 -0500, Trond Myklebust wrote:
> > On Fri, 2012-01-06 at 19:32 +0200, Sasha Levin wrote: 
> > > 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.
> > > [...]
> > 
> > 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.

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

-- 
Trond Myklebust
Linux NFS client maintainer

NetApp
Trond.Myklebust@netapp.com
www.netapp.com

Re: Boot regression caused by commit 6829a048

[Sasha Levin]

On Fri, 2012-01-06 at 18:16 -0500, Trond Myklebust wrote:
> 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.

> 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.

-- 

Sasha.

Re: Boot regression caused by commit 6829a048

[Chuck Lever]

On Jan 6, 2012, at 12:32 PM, Sasha Levin wrote:

> 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?

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.

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

Re: Boot regression caused by commit 6829a048

[Sasha Levin]

On Fri, 2012-01-06 at 13:29 -0500, Chuck Lever wrote:
> On Jan 6, 2012, at 12:32 PM, Sasha Levin wrote:
> 
> > 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?
> 
> 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

> 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="?


-- 

Sasha.