Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #167801 > unrolled thread

Timing issue with fstab NFS mounts

Back to article view | Back to linux.debian.user

Contents

  Timing issue with fstab NFS mounts Steve Matzura <sm@noisynotes.com> - 2016-05-13 09:50 +0200
    Re: Timing issue with fstab NFS mounts Dan Ritter <dsr@randomstring.org> - 2016-05-13 11:20 +0200
      Re: Timing issue with fstab NFS mounts Steve Matzura <sm@noisynotes.com> - 2016-05-13 13:00 +0200
        Re: Timing issue with fstab NFS mounts Dan Ritter <dsr@randomstring.org> - 2016-05-13 13:30 +0200
          Re: Timing issue with fstab NFS mounts David Wright <deblis@lionunicorn.co.uk> - 2016-05-13 16:10 +0200
    Re: Timing issue with fstab NFS mounts David Witbrodt <dawitbro@sbcglobal.net> - 2016-05-13 16:10 +0200

#167801 — Timing issue with fstab NFS mounts

While the rest of my system is just cherry, I have not yet been able
to solve the problem of why an NFS mount and associated binds don't
work unless and until I wait a minute or two after the system comes
up, then issue a 'mount -a'. I have tried putting 'mount -a'  into
/etc/init.d/rc.local, and still no happiness. Is there something I
need to check for before the fstab stuff starts, or should the NFS
mount and associated binds be taken out of fstab and dealt elsewhere?
This seems a kluge, but I cannot think of another way to get around
this problem.

Thanks in advance as always.

[toc] | [next] | [standalone]

#167803

On Fri, May 13, 2016 at 03:34:44AM -0400, Steve Matzura wrote:
> While the rest of my system is just cherry, I have not yet been able
> to solve the problem of why an NFS mount and associated binds don't
> work unless and until I wait a minute or two after the system comes
> up, then issue a 'mount -a'. I have tried putting 'mount -a'  into
> /etc/init.d/rc.local, and still no happiness. Is there something I
> need to check for before the fstab stuff starts, or should the NFS
> mount and associated binds be taken out of fstab and dealt elsewhere?
> This seems a kluge, but I cannot think of another way to get around
> this problem.

The options field in fstab should include "_netdev" for devices
which cannot be mounted until networking is stable.

-dsr-

[toc] | [prev] | [next] | [standalone]

#167806

Dan,

On Fri, 13 May 2016 05:12:56 -0400, you wrote:

>The options field in fstab should include "_netdev" for devices
>which cannot be mounted until networking is stable.

I have never heard of that option. I'll try it and report back. Now,
what about the lines for the binds that immediately follow the network
device? Do the binds still operate even if the network device isn't
online yet? In other words, does the mounting of devices processing
stop until the line in fstab with _netdev in its options field is
processed, then the binds run? If so, then this is the answer to a
humble man's prayer. I've been wrestling with this literally for
months.

[toc] | [prev] | [next] | [standalone]

#167809

On Fri, May 13, 2016 at 06:57:10AM -0400, Steve Matzura wrote:
> On Fri, 13 May 2016 05:12:56 -0400, you wrote:
> 
> >The options field in fstab should include "_netdev" for devices
> >which cannot be mounted until networking is stable.
> 
> I have never heard of that option. I'll try it and report back. Now,
> what about the lines for the binds that immediately follow the network
> device? Do the binds still operate even if the network device isn't
> online yet? In other words, does the mounting of devices processing
> stop until the line in fstab with _netdev in its options field is
> processed, then the binds run? If so, then this is the answer to a
> humble man's prayer. I've been wrestling with this literally for
> months.

fstab is always evaluated in the order you write it, from top to
bottom. However, not all mount commands are equivalent. The
usual call shortly after system boot is:

mount -a -t nonfs,nfs4,smbfs,cifs,ncp,ncpfs,coda,ocfs2,gfs,gfs2,ceph -O no_netdev

which says: mount everything except filesystems which are known to
be dependent on networks, and also avoid filesystems which are marked
as _netdev.

In this case, you want to mark all your bind mounts as _netdev
as well.

-dsr-

[toc] | [prev] | [next] | [standalone]

#167821

On Fri 13 May 2016 at 07:28:50 (-0400), Dan Ritter wrote:
> On Fri, May 13, 2016 at 06:57:10AM -0400, Steve Matzura wrote:
> > On Fri, 13 May 2016 05:12:56 -0400, you wrote:
> > 
> > >The options field in fstab should include "_netdev" for devices
> > >which cannot be mounted until networking is stable.
> > 
> > I have never heard of that option. I'll try it and report back. Now,
> > what about the lines for the binds that immediately follow the network
> > device? Do the binds still operate even if the network device isn't
> > online yet? In other words, does the mounting of devices processing
> > stop until the line in fstab with _netdev in its options field is
> > processed, then the binds run? If so, then this is the answer to a
> > humble man's prayer. I've been wrestling with this literally for
> > months.
> 
> fstab is always evaluated in the order you write it, from top to
> bottom.

That may be true in wheezy but not in jessie. man fstab is out-of-date
and appears to be either unaware of initrd or unconcerned about its
effects. Anyway, check out read_fstab_entry().

> However, not all mount commands are equivalent. The
> usual call shortly after system boot is:
> 
> mount -a -t nonfs,nfs4,smbfs,cifs,ncp,ncpfs,coda,ocfs2,gfs,gfs2,ceph -O no_netdev
> 
> which says: mount everything except filesystems which are known to
> be dependent on networks, and also avoid filesystems which are marked
> as _netdev.
> 
> In this case, you want to mark all your bind mounts as _netdev
> as well.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#167820

> While the rest of my system is just cherry, I have not yet been able

> to solve the problem of why an NFS mount and associated binds don't
> work unless and until I wait a minute or two after the system comes

> up [...]

Sounds like the normal 90-second NFS grace period to me -- a feature,
not a bug.  If I run 'journalctl | grep grace' on one of my machines
I get:

May 12 17:50:07 fileserver kernel: NFSD: starting 90-second grace period (net ffffffff81c64a00)


This _is_ configurable, but there is an open Debian (wishlist) bug
about that:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=601335


Some further discussion justifying the "lease time"/"grace period"
feature, including a possible workaround for the bug above, see:

https://access.redhat.com/solutions/42868


HTH,
Dave W.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web