Boot delays when doing NFS mounts

[daytooner]

I have this problem with F15,F16, and F17:

In /etc/fstab, I have an nfs mount defined. I even included the "bg" option so it would do retry the mount in background if it fails.

Problem is that it hangs for about 90 seconds doing the mount only when booting up. If I remove the mount from fstab, boot (without delay), login, then manually do the nfs mount, it happens without any delay.

Any ideas?

TIA

ken

[sea]

Whats the fstab line to mount is looking like?

[daytooner]

Originally Posted by sea

Whats the fstab line to mount is looking like?

porky:/nas   /mnt/nas   nfs   bg,relatime,nodiratime 0 0

This works fine in F14 (and before). Also, after the delay, the mount is there and working. I can umount it, then mount it again with no delay.

ken

[glennzo]

Here's mine:

PHP Code:

# Network export
server:/script /mnt/script nfs _netdev,auto 0 0 


There is no delay mounting this folder.

[sea]

Mine's looking like:

//ocean/Linux 	 /mnt/Linux 		cifs credentials=/etc/samba/smb.cred 0	0

But for some reason i dont have any delays if my NAS is powered off..

[daytooner]

I don't think my problem is with the mount parameters. I have been using the same fstab lines for a long time on F14 and before. And I just discovered that I cannot export a mount from my F15/F16/F17 installs. If I try to connect to one, I get "Connection refused"

What I did notice, though, is that for F15/F16/ F17 port 2049 (for nfs) is not open. It is open for F14.I have selinux disabled, as well as the firewall. So nothing should be blocking it.

Also, on F14, there are several "nfsd" processes running. For the later versions, there are none.

Has something changed with nfs for these later versions of Fedora?

This is really getting frustrating! Please help!

ken

[stevea]

Day' - does the export mount correclty - eventually ?

On F14 it seems you could live with port 2049 and no rpcbind on the server for an NSFv4 mount. Somewhere along the line it started requiring the gssapi and name mapper daemon processes and this (I think) this requires the rpcbind service or alternatively timeouts.

There were definitely some systemd snafus in the nfs startup in F16, and probably F15. My f14/f14 server/client arrangement was rock solid. I could hibernate or restart the net connection on the client and when restored the export was mounted. Despite a pm-suspend bug I submitted and was fixed, I never got that sort of reliable mount with f14/f16 NFSv4 (with a nod to 4.1). When I switched to f17 server and client a few weeks ago I saw some of that same unreliability remained. Th eNFS shares wouldn't remain mounted.

I'm fairly certain that the systemd dependencies ignore your 'bg' option when mounting NFS, and hang waiting for network configuration to complete. You can verify with
systemd-analyze plot > /tmp/foo ; filefox /tmp/foo
Or you can dig through the /lib/systemd files, but IIRC the main mount module is a binary.

However I switched to glusterfs and gave up on NFS. Back in F14 the older version of gluster requires manually creating a rather complex config file. The newer versions have a 'gluster' command that hides all the complexity. gluster only supports 1-to-1 uid, gid mapping, eliminates all the ancient rpc/rpcbind/gss SunMS complexity, overhead & cruft. Gluster has a lot of cluster sharing ,multi-peer, data duplication features that I don't use. It is rock-solid reliable on F17, and I tested on F16 w/o problems.

So if you need NFS for compatibility, then you'll have to deal with NFS, but if you are just sharing files between modern Linux distro's then I can recommend gluster. Performance is better than NFS, much faster on large file I/O and and still a clear winner for small files.