On Fri, 2008-05-30 at 01:11 -0700, Laurent Blume wrote:
> Could you post a sample of your Debian-side configuration? I've found NFSv4
> configuration to be frustrating by itself on Linux, and most information
> found from Google sums up to "disable it".
> I think that I'm using automounted homedirs didn't help, either, the Linux
> automounter isn't great.
# apt-get install autofs nfs-common
/etc/auto.home:
-----------------
*
-fstype=nfs4,proto=tcp,sec=sys,hard,intr,noatime,nodev,nosuid,rsize=32768,wsize=32768
storage:/export/home/&
/etc/idmapd.conf:
----------------------------
...
Domain = <same name as on solaris box>
...
/etc/default/nfs-common:
-------------------------------------
...
NEED_IDMAPD=yes
...
# /etc/init.d/nfs-common restart
# /etc/init.d/autofs restart
We do use private passwd files or NIS for name resolution, because we
did have problems with LDAP on the linux clients loosing its mind.
There are two problems that I do still see with NFSv4 and debian stable
linux clients:
1) High CPU utilization on the opensolaris NFS server when there is
concurrent access to a file (like .bash_history in home dirs) from
multiple hosts. This does work itself through, but does introduce long
pauses on the clients.
2) Linux NFSv4 on debian etch stable is not completely robust. Very
occassionally (6+ months) we see a linux client get wedged with kernel
msgs in syslog indicating corruption, which always point to the NFSv4
client module. When machine gets into this state the system will not
shutdown and has to be hard reset. (There have been improvements in
more recent kernels surrounding NFSv4, but we just have not gotten
around to verifying everything else works.)
Other than that the read caching of NFSv4 has been a real success in
some of our production deployments.
--
paul
