Die Performance-Verluste beim NTFS und bei der Verwendung von "davfs" sind einmal dem
FUSE (das gilt für beide, das Bild rechts zeigt auch die vier zusätzlichen Kontextwechsel bei jeder Operation, denn der "Dateisystem-Code" braucht dann ja auch noch welche, wenn er seinerseits die Daten irgendwoher lesen will) und einmal der "davfs"-Implementierung zuzuschreiben (das ist dann der Code in der rechten Seite der Grafik), wobei AVM hier eben auch eine ältere Code-Basis (1.3.3 vs. 1.5.4) verwendet.
Beim NTFS ist es die Version vom März 2015, die von 21.03.2016 hat es nicht mehr ins Release geschafft oder Tests haben gezeigt, daß die dort inzwischen behobenen Fehler bei der Verwendung im FRITZ!OS keine Relevanz haben. :mrgreen:
Ob eine neue Version irgendwo performanter arbeiten würde (egal ob NTFS oder davfs), weiß ich aber auch nicht.
Ein Upload startet halt erst dann, wenn die Datei komplett im Cache-Verzeichnis gelandet ist (wenn der Benutzer das Kopieren vor dem Ende abbricht, braucht man auch nichts auf den WebDAV-Server übertragen) und der (parallele) Auftrag zur Übertragung gestartet werden kann. Das ist ein dateibasierter Cache und kein blockbasierter.
- - - Aktualisiert - - -
Wenn wirklich jemand mit einer "index" spielen will, muß er sich noch ein paar zusätzliche Gedanken machen.
Die Position des Cache-Verzeichnisses wird in "/etc/webdav_control" ermittelt und da wird erst einmal jedes beschreibbare Volume verwendet, das dem Code als erstes in die Finger gerät. Eine Auswahl des Volumes mit dem meisten freien Platz oder dem "besseren" Dateisystem erfolgt dort nicht (deshalb eben auch die Möglichkeit, mit einem Cache auf einem NTFS-Volume gleich noch eine weitere FUSE-Runde für jeden Zugriff an Land zu ziehen) und es wird immer eine Konfigurationsdatei erzeugt, die von 5 GB Platz für den Cache ausgeht - egal wie groß das Volume wirklich ist.
AVM hat bei den Parametern eigene Schöpfungen hinzugefügt ... u.a. eine Begrenzung der Anzahl der Dateien im Cache mit dem Parameter "cache_files" - der findet sich dann in der "usb.cfg" wieder. Ob man am Handling von "cache_size" im Code von "davfs" auch etwas geändert hat und/oder was da passiert, wenn man bei voller Belegung des Cache mit noch zu übertragenden Dateien (limitiert durch "cache_size" oder "cache_files") weitere Dateien hinzufügen will, muß man dann auch erst einmal in aller Ruhe überprüfen. Es wäre ja (zumindest bei einigen Szenarien) extrem blöd, wenn wegen vollem Cache mit zu schreibenden Dateien gar kein lesender Zugriff mehr funktioniert, weil die gelesenen Dateien dort nicht abgelegt werden können. Theoretisch sollten noch nicht übertragene Dateien ja nicht einfach gelöscht werden, um Platz für neue zu schaffen.
-Man darf auch nicht ganz aus den Augen verlieren, daß die "davfs2"-Implementierung eher für viele und kleinere Dateien gedacht war (der Standardwert bei "cache_size" sind z.B. nur 50 MB) und da ist es am Ende vielleicht sogar schlauer, wenn man solche Backup-Szenarien mit diesen Datenmengen mit einer eigenen Software-Lösung (durchaus auch über die FRITZ!Box, aber eben nicht über "davfs2") umsetzt.
Verwendet man in beiden Fällen z.B. FTP (einmal bei der Übertragung auf die Box und einmal bei der (späteren) Übertragung auf den Server), tendiert der Protokoll-Overhead bei der Datenübertragung gegen Null (das ist immer noch einer der großen Vorteile des FTP, weshalb es wohl immer noch überlebt) und den "resume"-Support gibt's bei passendem FTP-Server und -Client auch noch gratis dazu.
Wenn man also per FTP auf die Box schreibt (auch hier hilft natürlich die Auswahl des passenden Dateisystems) und Dateien in einen Verzeichnis ablegt, dann wird das erst einmal von keinen weiteren Rahmenbedingungen als den Berechtigungen des verwendeten Benutzers und dem freien Platz zur Speicherung begrenzt - ggf. vom lahmen USB der Box, aber dazu muß die Verbindung zum FTP-Client schon besser als FE sein (also mehr als 100 MBit/s stabil abliefern), damit das (bei geeigneter Wahl von Dateisystem und Datenträger) überhaupt auffällt.
Anschließend erzeugt man in einem weiteren Verzeichnis (der "Queue") eine Datei mit einem "Auftrag" für die Übertragung der zuvor gespeicherten Datei und dann braucht es nur noch eine Software-Lösung auf der Box, die jetzt ihrerseits das Auftragsverzeichnis überwacht und diese Aufträge dann liest, auswertet, ausführt und nach Abarbeitung den Auftrag (und ggf. die lokale Datei auch noch) löscht.
Das ist alles kein wirklicher Aufwand (man kann sogar ohne Polling auskommen, wenn man sich auf die "inotify"-Schnittstelle stützt) und es hat vor allem eben den Vorteil, daß man die jeweils vorhandene Bandbreite optimal ausnutzen kann - ohne riesigen Protokoll-Overhead. Wer am Ende mehr Upload-Kapazität hat, als der Server bereit ist in einer einzelnen Verbindung abzunehmen, kann dann sogar simultane Uploads in Erwägung ziehen.
Je nachdem, wie heftig man da investieren will, kann man sogar QoS noch dazupacken, ggf. mit unterschiedlichen Datenraten je nach Zielserver oder auch unterschiedliche (Auftrags-)Queues mit Prioritäten verwenden, damit "wichtige" Files zuerst auf den Server übertragen werden.
Ob es für so etwas bereits eine fertige (Software-)Lösung gibt, weiß ich nicht (aber vermutlich gibt's auch dafür eine App - das ist ja praktisch dieselbe "Aufgabenstellung" wie beim früher üblichen Upload von vielen "Dateischnipseln" zu irgendwelchen Share-Hostern) ... ist aber vielleicht wieder alles besser mit wenig Aufwand per Shell-Code vom Prinzip her selbst zu realisieren und dann nach eigenem Geschmack weiterzuentwickeln. Shell-Code wieder deshalb, weil es dann außer einer etwas aufgebohrten BusyBox keine weiteren Programme (von Perl- bis Python-Interpreter oder "curl") braucht - wer sich damit besser fühlt, kann das natürlich auch damit machen, solange er nicht am Ende den Overhead wieder spürbar erhöht (außer er akzeptiert auch das).
(Da hilft nur ein 120Gbit/s SDSL Anschluss )
