TrueNAS: Mount unter /mnt - Erfahrungen

Seit 1-2 Jahren habe ich die Cloud-Sync-Funktion von TrueNAS bzw. FreeNAS genutzt, um die Daten einer Windows-Maschine zu sichern. Die zu sichernden Daten wurden unter Windows schreibgeschützt als Windows-Dateifreigabe freigegeben und dann mittels

mount_smbfs -N -I <Hostname> //<Hostname>/<Freigabename> /mnt/<Ordner des Mountpoints>

im Hostsystem über "Aufgaben" > "Init/Shutdown Scripts" direkt beim Start verbunden.

Das klappte in Kombination mit rsync und Dropbox an sich lange Zeit wunderbar.

Doch mit einem Update auf TrueNAS RC1 scheinte etwas nach wenigen Tagen auf dem System völlig aus dem Ruder zu laufen:

Der SMB-Daemon sowie der collect.-Daemon scheinten keine Antwort mehr zurückzugeben. War das System in diesem Zustand, konnte nicht mal mehr der Befehl "zfs" oder  "df" verwendet werden, "zpool" oder "mount" funktionierten allerdings. Es war auch noch jederzeit möglich mittels SSH  bzw. SCP die Daten der jeweiligen Pools abzurufen.

Zusätzlich "swappte" das System nach weiteren Tagen in diesem Zustand massiv. Pools, WebGUI-Dasboard und auch der "middlewared" Daemon liefen in zahlreiche Timeouts.

Hier lässt sich das Problem im Jira Bugtracker von iXSystems nachlesen, in welchem ich das Problem gemeldet hatte:

https://jira.ixsystems.com/browse/NAS-107900 (evtl. Anmeldung notwendig)

Hier wurde nach einiger Analyse erst ein Defekt der Hardware ins Spiel gebracht, was ich allerdings mit einigen Tests dann doch relativ schnell entkräften konnte.

Eine weitere Idee war das Ausschalten einiger virtueller Maschinen, da bhyve sich manchmal zu viele Ressourcen beansprucht und daher evtl. ein übermäßiges "swappen" möglich gewesen sein könnte.

Auch Autotune wurde testweise gesetzt, was die Problematik nur für wenige Tage behob. Das System war wieder instabil und die SMB-Shares funktionierten nicht mehr.

Auf die Ursache bin ich dadurch gestoßen, da der Cloud-Sync-Task immer auf einen Fehler lief, obwohl die virtuelle Manschine gestartet war und ich mit einer anderen Windows-Maschine problemlos auf die Freigabe zugreifen konnte. Auch WinSCP hat sich über die SCP-Sitzung völlig "aufgehängt", als ich in das gemountete Verzeichnis wechslen wollte.

Also versuchte ich den Mountpoint zu entfernen. Allerdings war dies nicht möglich. Sobald ich dies versuchte, hing der Befehl ewig.

Der "collectd" Daemon ist für die Bereitsellung von Informationen des Systems und der Sammlung von Statistiken zuständig. Dieser Dienst listet um z.B. den verfügbaren Speicherplatz der Pools ermitteln zu können auch alle gemounteten Dateisysteme auf. Wenn nun dort ein Timeout auftritt, weil das Remote-Dateisystem nicht reagiert bleibt der Dienst dort einfach hängen. Dies sah dann ungefähr so aus (hier lief nichts mehr):

Oct 14 14:00:56 <HOSTNAME> 1 2020-10-14T14:00:56.695705+02:00 <HOSTNAME>.kirgus.intra collectd 2108 - - Traceback (most recent call last):
  File "/usr/local/lib/collectd_pyplugins/disktemp.py", line 63, in read
    temperatures = c.call('disk.temperatures', self.disks, self.powermode)
  File "/usr/local/lib/collectd_pyplugins/disktemp.py", line 63, in read
    temperatures = c.call('disk.temperatures', self.disks, self.powermode)
  File "/usr/local/lib/python3.8/site-packages/middlewared/client/client.py", line 421, in call
    raise CallTimeout("Call timeout")
middlewared.client.client.CallTimeout: Call timeout

Da dies auch "df" betrifft (und höchstwahrscheinlich) auch Subroutinen für das Dateisystem-Handling, welches auch ZFS nutzt und diese Befehle für Abfragen durch "middlewared" genutzt werden, hat sich ein Domino-Effekt ergeben:

Durch zyklisches Ausführen einer Subroutine welche mount, df oder nutzt kam es nach einigen Tagen zu einem Timeout. Es füllte sich eine Warteschlange an Tasks in der Middleware. Als die Warteschlange gefüllt war reagierte das WebGUI nicht mehr bzw. middlewared gab keine Daten mehr zurück. Da "mount" direkt im Dateisystem verankert ist und der SMB-Daemon das Dateisystem für die Dateifreigabe verwenden muss, scheint dies einen blockenden Prozess hervorgerufen zu haben.

Nach dieser Analyse und dem Entfernen des Tasks Init-Scripts sowie einem Neustart lief das System wieder ohne Auffälligkeiten.

Es ist also seit neustem sehr wichtig, keine fremden (entfernten) Dateisysteme in TrueNAS zu mounten. Ich habe nicht getestet, ob sich das Verhalten auch bei einem abweichenden Mountpoint-Pfad wie z.B. unter /var/temp beobachten lässt. Jedenfalls kann so ein kleiner Mountpoint locker ein System enorm aus dem Gleichgewicht bringen.

Evtl. gibt es hier mittels syctls durchaus Möglichkeiten einen Timeout für entfernte Dateisysteme zu setzen, allerdings ist dieses "neue" Verhalten vorerst unbekannt und vor allem ist es für mich nicht wirklich ergründlich, warum der Befehl überhaupt in einem Timeout läuft, da die Freigabe generell einwandfrei zu funktionieren scheint. Ich werde vorerst eine andere Möglichkeit suchen, die Daten auf dem Hostsystem zur Verfügung zu stellen.