Re: Station diskless et Debian testing
Joël Bertrand, le mercredi 18 avril 2018 :
> Étienne Mollier a écrit :
> > C'est toujours ça de pris. Avec un peu de chance, désactiver
> > une tâche de fond du type à mettre à jour des caches pourrait
> > aider, typiquement mlocate/updatedb (m'enfin celui-ci n'est
> > censé ne tourner que quotidiennement par défaut, et n'était
> > probablement pas en train de tourner lors de vos essais).
>
> C'est le premier truc que je désactive.
Okay... :-)
> C'est un peu délicat. De toute façon, je n'ai que NFSv2
> et v3 côté NetBSD. Il y a bien le code NEW_NFS qui est le NFS
> de FreeBSD dans le noyau, mais il n'est pas aisément compilable
> et dans un état incertain. J'ai essayé de le compiler sans
> succès cet après-midi.
>
> Quoi qu'il en soit, je pourrais forcer un NFSv2, mais je
> ne suis pas sûr que ça améliorera les choses...
Okay, je vois le tableau ; vers=3 c'est très bien en l'état.
> Pour avoir continué mes essais, j'ai l'impression que le
> problème tourne autour de lockd. C'est lui qui semble partir en
> timeout. Côté serveur, j'ai un tas de :
>
> Apr 17 12:28:01 legendre rpc.lockd: no matching entry for hilbert
> Apr 17 12:28:01 legendre rpc.lockd: duplicate lock from hilbert.2
> Apr 17 12:28:01 legendre rpc.lockd: no matching entry for hilbert
> Apr 17 12:28:02 legendre rpc.lockd: duplicate lock from hilbert.2
> Apr 17 12:28:02 legendre rpc.lockd: no matching entry for hilbert
> Apr 17 12:28:04 legendre rpc.lockd: duplicate lock from hilbert.2
> Apr 17 12:28:04 legendre rpc.lockd: no matching entry for hilbert
> Apr 17 12:28:05 legendre rpc.lockd: duplicate lock from hilbert.2
> Apr 17 12:28:05 legendre rpc.lockd: no matching entry for hilbert
> Apr 17 12:28:05 legendre rpc.lockd: duplicate lock from hilbert.2
> Apr 17 12:28:05 legendre rpc.lockd: no matching entry for hilbert
>
> que je n'avais pas avant. J'ai essayé de remonter la partition
> /home (puisque c'est celle qui semble poser problème) avec
> l'option nolock et je n'obtiens qu'un :
>
> root@hilbert:~# mount -o remount,rw,nolock /home
> mount.nfs: an incorrect mount option was specified
Rien dans la documentation de nfs(5) ne suggère que ces options
soient erronées. Au pire, le "nolock" serait en contradiction
avec le "local_lock=none" déjà présent. Mais dans ce cas, cette
première option aurait dû avoir préséance.
Soit il y a une subtilité qu'on a loupé, par exemple vis-à-vis
d'un montage NFS effectué dans un autre montage NFS côté client ;
soit il y a légitimement un bug dans le client (ou le serveur)
NFSv3 vis-à-vis du montage dans ce genre de situation.
> Autre chose qui semble avoir changé. Mon fstab contient :
> 192.168.10.128:/srv/hilbert / nfs intr,tcp,nfsvers=3,async 0 0
> 192.168.10.128:/home /home nfs intr,tcp,nfsvers=3,async 0 0
> /swapfile.0 none swap sw 0 0
>
> Pourtant, les montages sont reconnus par le système
> comme :
> root@hilbert:~# nfsstat -m
> / from 192.168.10.128:/srv/hilbert
> Flags: rw,relatime,vers=3,rsize=65536,wsize=65536,namlen=255,hard,nolock,proto=tcp,port=2049,timeo=7,retrans=10,sec=sys,local_lock=all,addr=192.168.10.128
>
> /home from 192.168.10.128:/home
> Flags: rw,relatime,vers=3,rsize=65536,wsize=65536,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=192.168.10.128,mountvers=3,mountport=1020,mountproto=tcp,local_lock=none,addr=192.168.10.128
>
> Je suppose que c'est encore un coup de la bouse systemd
> qui modifie les options puisque / est monté avec un nolock et
> /home avec un lock.
Je vois mal quoi rajouter, à part espérer que forcer "nolock" ou
bien "local_lock=all" aux options de montage des / et /home
directement dans le fichier fstab permette de contourner ce
problème, et révèle in fine si ces options silencieusement
passées étaient bien la cause des ralentissements.
En espérant que ça aide un peu quand même,
À plus,
--
Étienne Mollier <etienne.mollier@mailoo.org>
Reply to: