Date: Thu, 29 Jan 2009 13:08:47 -0900 From: Mel <fbsd.questions@rachie.is-a-geek.net> To: freebsd-questions@freebsd.org Cc: Arjan van der Oest <arjan.van.der.oest@worldmax.nl> Subject: Re: [7.1-RELEASE-p2 amd64] NFS mount in fstab hangs during mountcritremote execution Message-ID: <200901291308.47418.fbsd.questions@rachie.is-a-geek.net> In-Reply-To: <FC5FF0B613540249959195342B6D034C754785@worldmax-sbs01.Worldmax.local> References: <FC5FF0B613540249959195342B6D034C754785@worldmax-sbs01.Worldmax.local>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thursday 29 January 2009 00:47:49 Arjan van der Oest wrote:
> Hi,
>
> I=E2=80=99m puzzled and either I don=E2=80=99t understand the boot rc.d p=
rocess or there is
> something wrong with it =E2=98=BA
>
> I have this 7.1-RELEASE-p2 amd64 machine compiled with a GENERIC kernel, =
so
> NFS support is baked right into the kernel by default. In fsstab I have
> this entry:
>
> <nfs server ip>:/data/nfs-shares/S1018SR18 /nfs-mounts/backupsrv =
=20
> nfs rw 0 0
>
> - why does the system tries to mount the nfs filesystem from the fstab
> while nfs_client_enable has been set to no in rc.conf?
Because there is no relation between the two. You could be using a 3rd part=
y=20
nfs kernel module.
> - why does the=20
> system seems to hang on the mountcritremote script although there seems no
> valid reason for that. I can imagine the network has not been fully
> configured yet when executing (indicated by the link UP message right aft=
er
> the mouning NFS filesystems line) but why will the script not continue
> after a few timeouts?
Because you are not aware of the following mount_nfs flags, you can put=20
in /etc/fstab:
-b If an initial attempt to contact the server fails, fork off a
child to keep trying the mount in the background. Useful for
fstab(5), where the file system mount is not critical to multi-
user operation.
-R Set the mount retry count to the specified value. The default=
is
a retry count of zero, which means to keep retrying forever.
There is a 60 second delay between each attempt.
-i Make the mount interruptible, which implies that file system
calls that are delayed due to an unresponsive server will fail
with EINTR when a termination signal is posted for the process.
-s A soft mount, which implies that file system calls will fail
after retrycnt round trip timeout intervals.
> And more bizarre: when interrupting the=20
> mountcritremote script the share has been actually mounted, so it seems t=
he
> 'mount -a -t nfs' command has actually been executed successfully.
Looks more like the server is not sending a "success" message or it got los=
t=20
in transit. If this is 100% reproducable, look into compatibility issues, b=
y=20
scaling down the NFS version for the mount and check firewall rules on both=
=20
ends.
=2D-=20
Mel
Problem with today's modular software: they start with the modules
and never get to the software part.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200901291308.47418.fbsd.questions>