Re: [gentoo-user] NFS tutorial for the brain dead sysadmin?

[Kerin Millar <kerframil@fastmail.co.uk>]

On 27/07/2014 17:55, J. Roeleveld wrote:
> On 27 July 2014 18:25:24 CEST, "Stefan G. Weichinger" <lists@xunil.at> wrote:
>> Am 26.07.2014 04:47, schrieb walt:
>>
>>> So, why did the "broken" machine work normally for more than a year
>>> without rpcbind until two days ago?  (I suppose because nfs-utils was
>>> updated to 1.3.0 ?)
>>>
>>> The real problem here is that I have no idea how NFS works, and each
>>> new version is more complicated because the devs are solving problems
>>> that I don't understand or even know about.
>>
>> I double your search for understanding ... my various efforts to set up
>> NFSv4 for sharing stuff in my LAN also lead to unstable behavior and
>> frustration.
>>
>> Only last week I re-attacked this topic as I start using puppet here to
>> manage my systems ... and one part of this might be sharing
>> /usr/portage
>> via NFSv4. One client host mounts it without a problem, the thinkpads
>> don't do so ... just another example ;-)
>>
>> Additional in my context: using systemd ... so there are other
>> (different?) dependencies at work and services started.
>>
>> I'd be happy to get that working in a reliable way. I don't remember
>> unstable behavior with NFS (v2 back then?) when we used it at a company
>> I worked for in the 90s.
>>
>> Stefan
>
> I use NFS for filesharing between all wired systems at home.
> Samba is only used for MS Windows and laptops.
>
> Few things I always make sure are valid:
> - One partition per NFS share
> - No NFS share is mounted below another one
> - I set the version to 3 on the clients
> - I use LDAP for the user accounts to ensure the UIDs and GIDs are consistent.

These are generally good recommendations. I'd just like to make a few 
observations.

The problems associated with not observing the first constraint (one 
filesystem per export) can be alleviated by setting an explicit fsid. 
Doing so can also help to avoid stale handles on the client side if the 
backing filesystem changes - something that is very useful in a 
production environment. Therefore, I tend to start at 1 and increment 
with each newly added export. For example:-

   /export/foo      *(async,no_subtree_check,fsid=1)
   /export/foo/bar  *(async,no_subtree_check,fsid=2)
   /export/baz      *(async,no_subtree_check,fsid=3)

If using NFSv3, I'd recommend using "nolock" as a mount option unless 
there is a genuine requirement for locks to be co-ordinated. Such locks 
are only advisory and are of questionable value. Using nolock simplifies 
the requirements on both server and client side, and is beneficial for 
performance.

NFSv3/UDP seems to be limited to a maximum read/write block size of 
32768 in Linux, which will be negotiated by default. Using TCP, the 
upper bound will be the value of /proc/fs/nfsd/max_block_size on the 
server. Its value may be set to 1048576 at the most. NFSv3/TCP is 
problematic so I would recommend NFSv4 if TCP is desired as a transport 
protocol.

NFSv4 provides a useful uid/gid mapping feature that is easier to set up 
and maintain than nss_ldap.

>
> NFS4 requires all the exports to be under a single foldertree.

This is a myth: 
http://linuxcostablanca.blogspot.co.uk/2012/02/nfsv4-myths-and-legends.html. 
Exports can be defined and consumed in the same manner as with NFSv3.

>
> I haven't had any issues in the past 7+ years with this and in the past 5+ years I had portage, distfiles and packages shared.
> /etc/portage is symlinked to a NFS share as well, allowing me to create binary packages on a single host (inside a chroot) which are then used to update the different machines.
>
> If anyone wants a more detailed description of my setup. Let me know and I will try to write something up.
>
> Kind regards
>
> Joost
>

--Kerin