Wie kann verhindert werden, dass das Schreiben in CIFS minutenlang blockiert?


7

Wenn Sie ein CIFS-Dateisystem von einem NetApp-Filer bereitstellen und Dateien mit mehreren Gigabyte darauf kopieren, bleibt der Kopiervorgang häufig minutenlang hängen. Der Kernel schreibt Nachrichten wie folgt in das Syslog:

Nov 15 14:03:15 myclient kernel: [173570.048387] CIFS VFS: sends on sock ffff88003a2d4000 stuck for 15 seconds
Nov 15 14:03:15 myclient kernel: [173570.049115] CIFS VFS: Error -11 sending data on socket to server
Nov 15 19:01:22 myclient kernel: [191466.594088] CIFS VFS: Server myfileserver has not responded in 120 seconds. Reconnecting...

Die letzte Nachricht kann sich tatsächlich wiederholen, bevor das Schreiben fortgesetzt wird. Während der Prozess hängt, kann er nicht getötet werden. Selbst Versuche, den Computer neu zu starten, hängen.

Der Server ist eine NetApp, deren Spezifikationen ich noch nicht kenne. Der Client besteht aus zwei Ubuntu 14.04 LTS-Maschinen, von denen eine virtuell ist (dies geschieht auf beiden). Ihre Kerne sind Version 3.5.0-54-genericund 3.13.0-68-genericsind.

Ich habe drei Fragen.

  1. Wenn Sie dieses Problem jemals gesehen haben, auf welcher Linux-Version?
  2. Wie kann dieses Problem überhaupt auftreten? Sollte die Unterstützung des CIFS-Dateisystems nicht intelligenter sein, als unterbrechungsfrei aufzulegen?
  3. Welche Mount-Optionen beseitigen dieses Problem garantiert?

Mein fstab-Eintrag sieht folgendermaßen aus (anonymisiert):

//myfileserver/path/to/mydirectory /mnt/mydirectory cifs credentials=mycredentialsfile,rw,sec=ntlmv2,forceuid,forcegid,file_mode=0644,dir_mode=0755,noserverino,nounix,user,noauto 0 0

Das Hinzufügen cache=nonebehebt das Problem nicht. Hinzufügen directioauch nicht: man mount.cifsbehauptet, es sei eine unterstützte Option, aber es ist nicht. Was ist scheint das Problem zu beheben , ist das Hinzufügen wsize=4096oder wsize=8192: so weit, meine Tests mit diesen Optionen blockier gezeigt. (Mit wsize=16384tritt das Abwürgen immer noch auf.)

Anstatt nur durch Ausprobieren vorzugehen, möchte ich verstehen, was vor sich geht, und das Problem mit 100% iger Sicherheit beseitigen. Können Sie mir sagen, warum dies geschieht oder was zu tun ist?

(Es wurden mehrere Fragen zu Ask Ubuntu, Unix & Linux und ServerFault gestellt, die wie dieses Problem aussehen, aber die meisten sind es nicht: Sie beschweren sich darüber, dass sie beim Lesen von Dateien oder im Leerlauf des Dateisystems stehen bleiben , während dies in meinem Fall der Fall ist tritt nie auf, das Abwürgen tritt nur beim Schreiben von Dateien auf)

Antworten:


6

Standardmäßig verwenden cifs-Mounts das Protokoll 1.0, das nicht nur veraltet ist, sondern auch weitgehend ineffizient ist und sich aus mehreren Gründen nicht gut aus dem Ruhezustand erholt.

Abhängig von Ihrer Servertechnologie können Sie vers=2.1mindestens oder verwenden vers=3.0.

Ich würde empfehlen, mit der Dokumentation oder dem Hersteller zu überprüfen, welche Version des SMB-Protokolls unterstützt wird, oder zumindest 3.0die Ausgabe des mountBefehls zu verwenden und zu konsultieren , um die ausgehandelte Version zu sehen.

Das Ändern eines neueren CIFS-Versionsprotokolls sollte einige oder alle Ihrer Blockierungsprobleme lösen und Ihnen effizientere Übertragungsgeschwindigkeiten ermöglichen.

Weitere Informationen finden Sie in der entsprechenden Frage zu CIFS, die zufällig die Verbindung zur Windows-Freigabe verliert .

Bitte beachten Sie, dass sich das Abwürgen verbessert , aber beim Kopieren großer Dateien nicht verschwindet. Dieses Verhalten ist eine Funktion, z. B. werden die Dateien in Puffer verschoben, und das Dateisystem wartet auf die Serverbenachrichtigung, dass die Kopie erfolgreich abgeschlossen wurde.


1
Danke, das war sehr hilfreich. Ich habe versucht vers, verschiedene Versionen einzustellen, aber das Problem wurde erst behoben, als wir auf einen neuen Dateiserver umgestiegen sind. Ich denke, es war spezifisch für die alte NetApp, die wir verwendet haben, und es hätte wahrscheinlich am Serverende behoben werden können, wenn wir uns darum gekümmert hätten.
Reinierpost
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.