Re: nfs mounts should have the 'nolocks' option
On 22 Apr 2000, Adam Di Carlo wrote:
> Bjoern Brill <brill@samson.math.uni-frankfurt.de> writes:
>
> > On 19 Apr 2000, Chris Baker wrote:
> > > I'm guessing you didn't mount /var with the `nolocks' option? Or
> > > maybe it's a different problem....
> >
> > It is this problem. dbootstrap doesn't mount /var with the "nolocks"
> > option (I can of course change fstab manually before booting
> > the new system, but dbootstrap should really take care about that).
> > The problem then is that locking fails on /var and, consequently, apt and
> > dselect fail when the new system is booted the first time to complete
> > the installation.
> >
> > NFS mounted partitions served by the Linux user space NFS server can't
> > use real NFS locks at all, so dbootstrap should include the "nolocks"
> > option into fstab. NFS mounted partitions served by the Kernel NFS server
> > or other Unices can use NFS locking, but AFAIK only if nfs-common (namely
> > rpc.statd) goes into base; this isn't the case at the moment.
> >
> > A possible solution would be:
> > dbootstrap just puts nolocks in fstab for every NFS mount.
>
> This seems feasible. Are there any foul implications of doing this?
> I.e., does it really apply to all architectures? What about NFS root
> situations?
>
(Thank you for correcting my careless choice of subject. Oh, and the
option is "nolock", not "nolocks" - my fault.)
foul implications: Problems could arise if files are shared by different
machines and the other machines use NFS locks and assume these are obeyed
(mail in mixed environments?). A single mounting machine shouldn't see
much difference since Linux fully emulates machine-local locking.
architectures: It seems unlikely that there be architecture-specific
changes to general things like NFS or locking (not counting hurd of
course) but I can't say for sure. To make sure I didn't see an m68k
specific effect I tested fcntl() locking by an i386 NFS client running
Linux 2.2.14 with the following results:
client \ server nfs-kernel-server nfs-server
-------------------------------------------------
rpc.statd up, nolock | OK OK
no rpc.statd, nolock | OK OK
rpc.statd up | OK ENOLCK
no rpc.statd | ENOLCK ENOLCK
NFS root: means that more, usually all, of the file system is
affected. There's nothing special about /var except that it contains an
especially large and important portion of potential locks. Generally,
using "nolock" when not necessary could make things less safe in some
setups, but on the other hand, all lock attempts failing because of
missing "nolock" means severe breakage.
> It seems like a bit of a drastic change and that worries me.
Agreed, but...
> > A better solution would be: nfs-common goes into base and on the
> > boot-floppies (it's really small). When the user tries to mount a
> > NFS share, dbootstrap creates a temporary file on the share and
> > tries to (NFS) lock it. If this succeds, we have a server that
> > supports NFS locking and don't use "nolocks" in fstab. Otherwise,
> > we put "nolocks" in fstab.
>
> It doesn't seem feasible to accomplish this at this time.
>
Well, then I don't know an alternative to the first solution. The last
line of above table means that otherwise locking fails on any kind of
NFS share when the new base system (without rpc.statd) is booted.
Would it make sense if dbootstrap at least alerted the user of what is
going on with a message box like
<gooddoggy:/lockme> will be mounted on </path> with the "nolock" option
since not all NFS servers support the NFS locking protocol. If you are
sure the server <gooddoggy:> supports locking you should refer to
<explanation.txt> for an explanation on how to change this after
the installation is completed.
? BTW: mount -o remount seems to be a no-op on NFS mounts. If the
partitions in question can't be unmounted (like /var), I don't know
how to change mount options without going down to maintenance mode
or reboot.
Regards,
Bjoern Brill
--
Bj"orn Brill <brill@fs.math.uni-frankfurt.de>
Frankfurt am Main, Germany
Reply to: