hashdeep mit Multi-Threading

[Matjes]

Hallo zusammen,

nach einem Nachmittag "Forschung und Technik" konnte ich dem Zuständigen einen Testfall hinstellen, der den Bug kristallklar darstellt.

Grund für den Absturz:
Bei Parameter -j0 werden anscheinend von hashdeep.exe mehrere Environment-Variablen gesetzt.
Ist das Environment bereits durch mehrere Variablen belastet, führt dieses Setzen der zusätzlichen Environment-Variablen zum Überlauf des Environment und damit zum Abbruch.
Mit Parameter -j1 tritt das Verhalten nicht auf.

Fehler ist vom Zuständigen nachvollzogen und in die Fehlerdatenbank eingetragen. Am patch wird gearbeitet.

Warum trat das bei mir auf:
Ich benutzte AlBundys wsusoffline_download.cmd. Dort werden alle Infos aus der UpdateGenerator.ini in Environment-Variablen gespeichert. Dadurch wird das Environment schon etwas belastet. Aus der weiteren Belastung durch hashdeep.exe resultiert dann der Crash.

Grüße Matjes

[aker]

@Matjes
Das hieße, es funktioniert mit dem Parameter -j0, wenn der Update-Generator verwendet wird?

Viele Grüsse

[boco]

Es gilt die Faustformel für den Parameter -j: die Zahl muss um 1 kleiner sein als die Anzahl der Prozessoren.

Natürlich vorausgesetzt, daß es mehr als eine CPU/Core ist.

[Matjes]

@aker
jo
Gruß Matjes

[Denniss]

Gibt es inzwischen eine Besserung mit dem Parameter -j0 ?
Ich habe den jetzt bei mir gesetzt da mir die Festplatte zu stark belastet wurde beim Abgleich der Dateien (große Partition, Dateien sind wohl über die ganze Partition verteilt).

Wird bei einem Audit-Fehler eigentlich der Name der fehlerhaften Datei(en) angegeben oder gibt es nur eine nichtssagende Fehlermeldung?

[Matjes]

Hallo Denniss,

wenn dein Environment nicht startk durch gesetzte Variablen belastet ist, sollte es mit j0 funktionieren.

Bei stark belastetem Environment kommt es mit -j0 zum Absturz von hashdeep.
Fehler ist im Status Open.
http://sourceforge.net/tracker/?func=de ... tid=516778

Gruß Matjes

[Gerby]

Gibt es inzwischen eine Besserung mit dem Parameter -j0 ?

In der neuen Version 4.1.1 ist der Fehler offensichtlich noch nicht behoben, da nicht erwähnt:

** Changes in version 4.1.1 (5 Jun 2012)

* New Features

* Bug Fixes

Fixed hashdeep bug for known files with commas in their names.
Cleaned up usage message

Der Tracker-Eintrag bestätigt das (Status: Open, Resolution: None).

Ich habe den jetzt bei mir gesetzt da mir die Festplatte zu stark belastet wurde beim Abgleich der Dateien (große Partition, Dateien sind wohl über die ganze Partition verteilt).

Jepp, hier und da ist mir das Festplattengerödel auch schon aufgefallen. Die Sache mit dem Multithreading bringt in solchen Fällen wohl eher Zeitnachteile als -vorteile. Auch die Festplatte wird dadurch ja mehr belastet. Eventuell ist es tatsächlich besser, auf das Multithreading zu verzichten.

Da der "-j0"-Parameter zum Abstellen des Multithreadings bei der 4-er-Version des hashdeep-Tools wie erwähnt hier und dort Probleme bringt, ist die Verwendung der letzten 3-er-Version 3.9.2 (noch ganz ohne Multithreading) denkbar; dann müsste halt auch der "-j"-Parameter überall rausfliegen. Oder gab's auch schon Probleme mit der 3-er-Version?

Das nur mal so als Einwurf in eine Diskussion.

Gruß
Gerby

[boco]

Man muß ganz klar zwei Szenarien unterscheiden. Nee, eigentlich drei:
1. Magnetische Festplatte älterer Bauart ohne NCQ (Native Command Queueing). Hier würde ich ganz klar Single-threading empfehlen, da dieses dem sequentiellen Lesen am nächsten kommt.

2. Magnetische Festplatte modernerer Bauart mit NCQ. Diese Platte optimiert die Anzahl der Bewegungen des Lese-/Schreibkopfs, indem die Reihenfolge der Lese-/Schreiboperationen umgestellt wird. Deutlich performanter bei Multi-threading, hier müßte man es testen.

3. SSD. Keine Frage, dieses Laufwerk hat keinerlei Probleme mit Multithreading.


Abschließend läßt sich sagen, bei herkömmlichen Konfigurationen ist immer noch die Platte der Flaschenhals. Eine möglichst sequentielle Bearbeitung der Daten ist wohl hier das Optimum.


WSUSUpdateAdmin: Trotzdem sollte doch zumindest hashdeep in der neuesten Version in WSUSOU Einzug finden, nicht?

[Gerby]

WSUSUpdateAdmin: Trotzdem sollte doch zumindest hashdeep in der neuesten Version in WSUSOU Einzug finden, nicht?

http://trac.wsusoffline.net/changeset/363/trunk (Oder wolltest Du einfach nur mit Torsten d'accord gehen?)

Falls auch von Torsten die Single-Thread-Lösung bevorzugt werden sollte, ist zur Zeit wohl noch die 3-er-Version von hashdeep in Hinsicht auf die Gewährleistung der Funktion die bessere Wahl (im Vergleich zur fehlerhaften j0-Implementierung oder zum j1-Parameter mit zwei Threads bei der 4-er-Version).

[boco]

http://trac.wsusoffline.net/changeset/363/trunk (Oder wolltest Du einfach nur mit Torsten d'accord gehen?)

Üblicherweise checke ich den Trac vor dem Forum (wegen Signatur und so). Deshalb kann sich das überschnitten haben. War zu dem Zeitpunkt noch nicht drin.
Davon abgesehen sollte man immer die neueste Version eines Tools verwenden (solange es keine Beta ist oder andere wichtige Gründe vorliegen). Der APPCRASH is natürlich übel, hoffentlich kommt der Macher mal in die Gänge...