Das NFS idmap Problem erscheint immer seltsamer. Weil es Linux ist, gibt es
	  mehr als eine Methode, die Userid des Owners zu ermitteln:
	    https://www.kernel.org/doc/Documentation/filesystems/nfs/idmapper.txt
	  Entweder rpc.idmapd oder request-key. Letzteres mal schnell wie dokumentiert
	  ausprobiert, funktioniert nicht. Also weiter rpc.nfsidmapd debuggen...
	Failover auf nextwo ausgefuehrt, resilvering laeuft.
	Man kann ein OpenSolaris/NexentaOS zum genauen Nachschaun nach Hardware beim
	  Bootup bringen, wenn man vor dem shutdown ein File /reconfigure anlegt...

[/bauerm] permanent link

	Wir sind Mitglied in einem grossen Club, wie sich rausstellt:
		  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=758870
		  https://bugs.launchpad.net/fedora/+bug/1124250
		  http://article.gmane.org/gmane.linux.nfs/67156 
	  Das mit dem nfsidmap ist ein Kernel Problem, und als solches
	  bekannt seit 2013. Betrifft auch viel kleinere Installationen als unsere.
	  Vollkommen krank, die haben neben den rpc.idmapd (der in services status nicht
	  auftaucht) noch einen wirren key-request mit eigenem in-kernel Cache
	  gebaut, und diese Caches voellig unterdimensioniert. Ausserdem
	  scheint er ein "kenn ich nicht" ewig zu cachen, so dass ein nicht-Erkennen
	  wegen Speichermangel zu ewigem nicht-Erkennen fuehrt (deswegen scheint
	  das nfsidmap -c zu helfen, dass leert die Caches, und dann wird neu probiert).
	  Einen hotfix mit heisser Nadel gestrickt, der jetzt im Betrieb die
	  Groessen der Caches per sysctl hochsetzt. So ein Roooooooootz.

[/bauerm] permanent link