Systemkollaps

[Tom]

Hello,

ich habe hier veraschiedene Threads zu Spezialfragen des gesamtem Problems gehabt die letzten Tage, und im Dialog mit den kritischen Könnern auch so einiges richten können.

Allerdings hab ich noch ein Problem...

Durch das erstellte Tool werden in der Produktion später bis zu 10.000 Files gegeneinander abgeglichen, ob sie denselben Inhalt haben und ihre im Fileheader befindlichen Metadaten abgestimmt.

Nun haben wir aus Systemgründen die Files auf diversen WinDOSen liegen, die Applikation mit der Datenbank, in der dann die Kernergebnisse zusammengefasst werden, liegt aber auf einem Linuxhost. Die Verzeichnisse der WinDOSen werden per mount-Befehl einbezogen.

Da das Prüfprogramm den Inhalt des Files beliebig oft benötigt über Namen (sonst muss ich alle einbezogenene Klassen umschreiben) , also beliebig viele Connections pro Durchgang zum File aufbaut, habe ich dazu entschlossen, die Files vorher als TMP-File in das lokale Dateisytem zu ziehen.

Das hat auf meinem WinDOSen-Testrechner im Moment auch einen positiven Effekt bis zu einer bislang unbestimmten Anzahl zu prüfender Files. danach wird das System langsamer als vorher.

Ich gebe da dem verwendeten Filesystem (FAT32) die Schuld, da die gelöschten TMP-Files (zumindest deren namen) sich ja in Wirklichkeit noch in der Chain of Files befinden und es im Directory immer mehr werden. Den passenen File zu finden (wenn schon 10.000 in der Kette stehen) wird also immer schwieriger.

Bei den (Win)DOSen hilt da nur ein "Verzeichnis umkopieren" oder ein Defrag.

Langer Rede kurze Frage:

Wie sieht das bei Linux-Filesystemen wie z.B. ext2 oder
  reiserFS aus?

Werden die durch Anlegen und wieder Löschen von Files auch immer langsamer?

Harzliche Grüße vom Berg
http://www.annerschbarrich.de

Tom

[Christian Seiler]

Hallo Tom,

Ich gebe da dem verwendeten Filesystem (FAT32) die Schuld, da die gelöschten TMP-Files (zumindest deren namen) sich ja in Wirklichkeit noch in der Chain of Files befinden und es im Directory immer mehr werden. Den passenen File zu finden (wenn schon 10.000 in der Kette stehen) wird also immer schwieriger.

Das habe ich zwar noch nie gehört, aber ich habe eh nicht viel mit FAT am Hut, daher lasse ich das mal so stehen.

Wie sieht das bei Linux-Filesystemen wie z.B. ext2 oder
  reiserFS aus?

Werden die durch Anlegen und wieder Löschen von Files auch immer langsamer?

Kommt darauf an[tm]. Grundsätzlich erstmal nicht (zumindest ext2, ich nehme aber auch mal stark an bei reiserfs genauso). Wenn eine Datei gelöscht wird, ist es dafür bei diesen Dateisystemen recht schwierig, sie wiederherzustellen (im Gegensatz zu FAT, wo das relativ leicht möglich ist). Allerdings hängt das auch davon ab, wie viel Plattenplatz noch frei ist. Wenn viel Plattenplatz frei ist, fragmentieren die beiden Dateisystem so gut wie überhaupt nicht, wenn wenig Plattenplatz frei ist, fragmentieren diese Dateisysteme und dadurch geht die Performance in die Knie.

Viele Grüße,
Christian

[Der Martin]

Hallo Tom,

[...] bis zu einer bislang unbestimmten Anzahl zu prüfender Files. danach wird das System langsamer als vorher.
Ich gebe da dem verwendeten Filesystem (FAT32) die Schuld, da die gelöschten TMP-Files (zumindest deren namen) sich ja in Wirklichkeit noch in der Chain of Files befinden und es im Directory immer mehr werden.

das ist so nicht ganz richtig. Die FAT-Dateisysteme (egal ob FAT12, FAT16 oder FAT32) verwenden Verzeichniseinträge, die durch das Löschen von Dateien frei geworden sind, beim Anlegen des nächsten Eintrags wieder, so dass die Gesamtlänge (=Anzahl der Sektoren) eines Verzeichnisses gegen einen bestimmten, annähernd konstanten Wert geht, wenn ebensoviele Dateien gelöscht wie neu angelegt werden.
Allerdings wird die für das Verzeichnis reservierte Clusterkette im normalen Betrieb nie wieder verkürzt, selbst wenn von 2000 Dateien irgendwann z.B. 1700 wieder gelöscht werden. In diesem Fall kommt deine Aussage zum Tragen, dass nur ein Defragmentieren oder ein Umkopieren des Verzeichnisses hilft.

Den passenen File zu finden (wenn schon 10.000 in der Kette stehen) wird also immer schwieriger.

Das hängt bei FATxx linear von der Länge des Verzeichnisses (größte Anzahl Einträge, die es je hatte) ab, weil FAT-Verzeichnisse unsortiert angelegt werden. Die scheinbare Sortierung übernimmt höchstens die Shell, also der Explorer, beim Anzeigen. Beim Öffnen einer Datei muss das Verzeichnis also linear durchsucht werden.

Schönes Wochenende noch,
 Martin

[Tom]

Hello,

das ist so nicht ganz richtig. Die FAT-Dateisysteme (egal ob FAT12, FAT16 oder FAT32) verwenden Verzeichniseinträge, die durch das Löschen von Dateien frei geworden sind, beim Anlegen des nächsten Eintrags wieder, so dass die Gesamtlänge (=Anzahl der Sektoren) eines Verzeichnisses gegen einen bestimmten, annähernd konstanten Wert geht, wenn ebensoviele Dateien gelöscht wie neu angelegt werden.

Du hast Recht. Ich schreibe ja  nicht erst alle drauf und lösche sie dann, sondern schreibe ein File, und lösche es dann wieder. Da bin ich jetzt aber trotzdem gespannt, wieso das so immer langsamer wird...

Allerdings wird die für das Verzeichnis reservierte Clusterkette im normalen Betrieb nie wieder verkürzt, selbst wenn von 2000 Dateien irgendwann z.B. 1700 wieder gelöscht werden. In diesem Fall kommt deine Aussage zum Tragen, dass nur ein Defragmentieren oder ein Umkopieren des Verzeichnisses hilft.

Was dann dazu führen kann, dass die Platte "voll" ist, obwohl kaum etwas drauf ist.
Die verfügbaren Cluster verstecken sich in irgendeinem (inzwischen unbenutzten) Unterverzeichnis.

Harzliche Grüße vom Berg
http://www.annerschbarrich.de

Tom

[Vinzenz Mai]

Hallo Tom,

Was dann dazu führen kann, dass die Platte "voll" ist, obwohl kaum etwas drauf ist.
Die verfügbaren Cluster verstecken sich in irgendeinem (inzwischen unbenutzten) Unterverzeichnis.

wieso denn das. Ob ein Cluster verfügbar ist oder nicht, das wird ausschließlich anhand der FAT-Einträge ermittelt. Diese verstecken sich nicht in irgendwelchen Unterverzeichnissen. Es kann höchstens zu sogenannten verlorenen Clustern kommen, d.h. Cluster die in der FAT als belegt markiert sind, für die (bzw. deren Kette) es jedoch keinen Anfang in einem Verzeichniseintrag gibt. Ein ähnlicher Fehler sind zwei Clusterketten, die irgendwann auf den gleichen Folgecluster zeigen. Zum Aufspüren solcher Fehler und dem Bereinigen dient unter NT-ähnlichen-Betriebssystemen chkdsk.

Natürlich kann ich überhaupt nicht verstehen, warum man unter Windows 2000 überhaupt noch FAT einsetzt. Seit Windows NT 4.0 (und schon vorher unter einem Rechner mit Windows NT 3.51) setze ich auf NTFS und habe damit ausgezeichnete Erfahrungen gesammelt. Für den temporären Kram empfehle ich eine eigene Partition, die man von Zeit zu Zeit ganz einfach formatiert (natürlich mit Quickformat), die schnellste Defragmentierung, die es gibt.

Freundliche Grüße

Vinzenz

[Ashura]

Hallo Vinzenz.

Natürlich kann ich überhaupt nicht verstehen, warum man unter Windows 2000 überhaupt noch FAT einsetzt.

Zum Beispiel wenn ein GNU/Linux-System als Zweitsystem uneingeschränkten Schreibzugriff haben soll, ist NTFS sehr ungünstig.

Einen schönen Sonntag noch.

Gruß, Ashura

[Tom]

Hello,

Natürlich kann ich überhaupt nicht verstehen, warum man unter Windows 2000 überhaupt noch FAT einsetzt.

Zum Beispiel wenn ein GNU/Linux-System als Zweitsystem uneingeschränkten Schreibzugriff haben soll, ist NTFS sehr ungünstig.

Ich habe es auch noch nicht geschafft ReiserFS (oder eben auch NTFS) auf meinen Smart Memory Cards zu installieren ;-))

Harzliche Grüße vom Berg
http://www.annerschbarrich.de

Tom

[Vinzenz Mai]

Hallo Ashura,

Natürlich kann ich überhaupt nicht verstehen, warum man unter Windows 2000 überhaupt noch FAT einsetzt.
Zum Beispiel wenn ein GNU/Linux-System als Zweitsystem uneingeschränkten Schreibzugriff haben soll, ist NTFS sehr ungünstig.

ich hätte "im Produktiveinsatz" hinzufügen sollen. Einen Rechner im Produktiveinsatz mit Dualboot zu konfigurieren, halte ich für einen konzeptionellen Fehler. Privatrechner, Testrechner und ähnliches sind eine andere Geschichte.

Im von Tom beschriebenen Fall halte ich ein Zweitsystem für groben Unfug. Für temporäre Daten wäre meiner Meinung nach eine eigene Partition die beste Lösung mit Formatieren statt Defragmentieren. Es muss nur dafür gesorgt werden, dass zum Formatierungszeitpunkt kein Zugriff auf die Partition erfolgt.

Freundliche Grüße

Vinzenz

[Der Martin]

Hallo Vinzenz,

Was dann dazu führen kann, dass die Platte "voll" ist, obwohl kaum etwas drauf ist.
Die verfügbaren Cluster verstecken sich in irgendeinem (inzwischen unbenutzten) Unterverzeichnis.

wieso denn das. Ob ein Cluster verfügbar ist oder nicht, das wird ausschließlich anhand der FAT-Einträge ermittelt.

Eben drum. Die Crux ist ja, dass die Clusterketten, die ein Verzeichnis aufnehmen, nach Bedarf verlängert werden, wenn mehr Einträge dazukommen, aber nachträglich nicht mehr verkürzt werden, auch wenn sie nur ungenutzte Einträge enthalten. Die Verzeichniseinträge werden als unbenutzt markiert, die Cluster, in denen sie liegen, sind aber in der FAT noch als "belegt" gekennzeichnet.

Diese verstecken sich nicht in irgendwelchen Unterverzeichnissen.

Doch, in gewissem Sinn schon. Verzeichnisse werden im FAT-Filesystem ganz genauso verwaltet wie Dateien und belegen damit auch Speicherplatz, der im Directory-Listing aber nirgends angezeigt wird. Ein chkdsk oder scandisk ist AFAIK die einzige Methode, wenigstens für den gesamten Datenträger den durch Verzeichnisse belegten Speicherplatz abzufragen. Für einzelne Verzeichnisse kommst du an diese Info leider nicht dran.

Es kann höchstens zu sogenannten verlorenen Clustern kommen, d.h. Cluster die in der FAT als belegt markiert sind, für die (bzw. deren Kette) es jedoch keinen Anfang in einem Verzeichniseintrag gibt. Ein ähnlicher Fehler sind zwei Clusterketten, die irgendwann auf den gleichen Folgecluster zeigen. Zum Aufspüren solcher Fehler und dem Bereinigen dient unter NT-ähnlichen-Betriebssystemen chkdsk.

Richtig, oder mittlerweile scandisk. chkdsk wird nur aus Nostalgiegründen noch unterstützt und ist nur ein abgespecktes scandisk ohne GUI.

Natürlich kann ich überhaupt nicht verstehen, warum man unter Windows 2000 überhaupt noch FAT einsetzt.

Oh, ich schon. Weißt du doch. :-)

Schönen Sonntag noch,
 Martin

[Tom]

Hello Vinzenz,

wieso denn das. Ob ein Cluster verfügbar ist oder nicht, das wird ausschließlich anhand der FAT-Einträge ermittelt.

Du bringst mich ganz durcheinander...

Am Anfang hängen alle verfügbaren Cluster als verkettete Liste hintereinander.
Je nachdem, ob FAT12, FAT16 oder FAT32 verwendet wird, ergeben sich die Zuordnungen

Cluster<->FAT-Eintrag

direkt aus der Position in der FAT (position equals cluster number) oder eben über Berechnung. Zumindest ist jedem "Datensatz" in der FAT direkt ein Cluster zugeordnet.

Wenn jetzt in einem Verzeichnis eine Datei angelegt wird, wird Ein Cluster aus der Hauptkette herausgenommen und sein Index in den Dateieintrag geschrieben. Diese Datei zeigt jetzt also auf ihr Startcluster. Dieses Startcluster erhält in seinem korrespondierenden FAT-Datensatz den Eintrag "LC/F" = "Last Cluster in File" =

FAT12:           0xFF8 -      0xFFF
FAT16:          0xFFF8 -     0xFFFF
FAT32       0x?FFFFFF8 - 0x?FFFFFFF

Wenn nun eine neue Datei im Verzeichnis angelegt werden soll, wir erst geschaut, ob es gelöschte Files gibt (Erstens Zeichen = 0x05, wenn ich nicht irre) und die dann wiederverwendet.

Die Fileinformationen stehen in Directory-Files, die zu Datensätzen à 32 Bytes organisiert sind.
Wenn nun ein File gelöscht wird, wird _nicht_ die Clusterkette zurückgegeben an die Hauptkette, sondern sie belibt ungenutzt liegen, bis zufällig in diesem Directory wieder ein File angelegt werden soll.

Was passiert aber nun mit der Restcluster-Kette, wenn das neue File weniger Platz benötigt, als das alte? Die könnte nämlich erstens als "Luschenfile" im Directory verbleiben, oder aber sie könnte der Hauptclusterkette zurückgegeben werden.

Soviel Zeit hatte ich aber weder gestern noch heute, dies qualifiziert in
http://www.microsoft.com/whdc/system/platform/firmware/fatgen.mspx
nachzulesen.

Ich habe auch immer nur ein File angelegt und diese dann nach Gebrauch gleich wieder gelöscht, bevor ich das nächste Temporärfile angelegt habe. Da lag also mein Trugschluss, dass die Chain of Directory Entries (mit den enthaltenen Filenamen) immer länger werden würde.

Bei den zu bearbeitenden Datenmengen muss ich allerdings auf "Hardwareverträglichkeit" achten.

Übrigens haben mich Svens und Martins Betrachtungen noch auf neue gute Ideen gebracht, ...
Die Identifikation der untersuchten Files wird immer besser :-))

Harzliche Grüße vom Berg
http://www.annerschbarrich.de

Tom

[Der Martin]

Hallo Tom,

Am Anfang hängen alle verfügbaren Cluster als verkettete Liste hintereinander.

nein, das ist ein falscher Ansatz. Die verfügbaren (also nicht belegten) Cluster liegen vielmehr als Haufen beisammen, ganz gewiss aber nicht als Kette. Verfügbare Cluster sind in der FAT immer mit 0 gekennzeichnet. Da die Cluster-Numerierung mit 2 beginnt, ist diese Kennzeichnung eindeutig von "richtigen" Folgeclusternummern unterscheidbar.

Je nachdem, ob FAT12, FAT16 oder FAT32 verwendet wird, ergeben sich die Zuordnungen
  Cluster<->FAT-Eintrag
direkt aus der Position in der FAT (position equals cluster number) oder eben über Berechnung.

Nein, diese Zuordnung ergibt sich *immer* aus der Position in der FAT.

Zumindest ist jedem "Datensatz" in der FAT direkt ein Cluster zugeordnet.

Ja, das auf jeden Fall.

Wenn nun eine neue Datei im Verzeichnis angelegt werden soll, wir erst geschaut, ob es gelöschte Files gibt (Erstens Zeichen = 0x05, wenn ich nicht irre) und die dann wiederverwendet.

Ja; in alten DOS-Zeiten, als Dateinamen noch keine Sonderzeichen >0x80 enthalten durften, wurde ein freier Eintrag auch mit 0xE5 markiert.

Die Fileinformationen stehen in Directory-Files, die zu Datensätzen à 32 Bytes organisiert sind.

Richtig. Als kleines Schmankerl noch: Für den "langen" Dateinamen werden zusätzliche 32byte-Records im Verzeichnis verwendet, so dass ein kompletter Verzeichniseintrag dann auch z.B. 5 oder 8 dieser 32byte-Records belegen kann.

Wenn nun ein File gelöscht wird, wird _nicht_ die Clusterkette zurückgegeben an die Hauptkette, sondern sie belibt ungenutzt liegen, bis zufällig in diesem Directory wieder ein File angelegt werden soll.

Du meinst die Clusterkette, die das Verzeichnis selbst enthielt? Dann ist es richtig. Denn die Clusterkette, die den Dateiinhalt aufnahm, wird sehr wohl wieder dem Pool der freien Cluster zugeordnet (FAT-Eintrag: 0).

Was passiert aber nun mit der Restcluster-Kette, wenn das neue File weniger Platz benötigt, als das alte? Die könnte nämlich erstens als "Luschenfile" im Directory verbleiben, oder aber sie könnte der Hauptclusterkette zurückgegeben werden.

Hä? Jetzt wird's geheimnisvoll. Welche Restcluster-Kette meintest du nun wirklich? Die der Datei selbst? Die gibt es nach dem Löschen nicht mehr. Die freien Cluster bilden keine Kette, siehe oben. Das ist mit ein Grund, warum das Rekonstruieren gelöschter Dateien manchmal problematisch ist, selbst wenn seit dem Löschen nichts mehr auf diesem Volume geschrieben wurde: Aus dem noch lesbaren Verzeichniseintrag kann man Startcluster und Dateigröße ablesen. Aber es ist nicht sicher, dass die Folgecluster (diese Info fehlt jetzt nach dem Löschen) systematisch fortlaufend belegt wurden. Eine Datei kann durchaus die Cluster 422,423,424,616,81,82 und 83 in genau dieser Reihenfolge belegen. Sowas ist hinterher praktisch nicht mehr automatisch rekonstruierbar.

Soviel Zeit hatte ich aber weder gestern noch heute, dies qualifiziert in
http://www.microsoft.com/whdc/system/platform/firmware/fatgen.mspx
nachzulesen.

Boah. Ich wusste gar nicht, dass Microsoft diese Spec nun offiziell zur Verfügung stellt. Ich habe vor ein paar Jahren mal entsprechende Info gesucht, da gab's aber nichts. Man war als Programmierer darauf angewiesen, durch Experimente und Analyse selbst herauszufinden, wie's läuft.
Werde ich mir in einer ruhigen Stunde sicher mal durchlesen, danke für den Hinweis.

Übrigens haben mich Svens und Martins Betrachtungen noch auf neue gute Ideen gebracht, ...
Die Identifikation der untersuchten Files wird immer besser :-))

Danke, das höre ich gern. Dann würde mich das Endergebnis aber auch irgendwann interessieren!

So long,
 Martin

[Tom]

Hello,

[...] much stuff!

Ich muss mich da in einer ruhigen Minute aber auch nochmal reschlauen ;-)

Speziell der Unterscheid zwischen (FAT 12, FAT16) | (FAT32) ist doch erheblich.

Jedenfalls bleiben nach Deinem Vortrag also nur die Verzeichniseinträge und die dazugehörigen langen Dateinamen zurück, die ja nach Lesen der MS-Spec auf in UTF-8 vorliegen können, und daher bei einer effektiven Länge von 255 Zeichen (das habe ich jeztzt nicht genau nachgeschaut, ob es denn nur 248 sind) durchaus 1kByte Speicherplatz belegen können...

Da ich TEMPNAM() benutzt habe mit Präfix "check_" könnte das schon ein Grund für eine Zeitverzögerung sein. Allerdings nicht für die derartig merkliche. Das muss noch einen anderen Grund haben. Den find ich aber auch noch :-))

Harzliche Grüße vom Berg
http://www.annerschbarrich.de

Tom

[Der Martin]

Hi Tom,

[...] much stuff!

how very true.

Speziell der Unterscheid zwischen (FAT 12, FAT16) | (FAT32) ist doch erheblich.

Eigentlich nicht. Die wesentlichen Unterschiede sind, dass ...

* der Bootblock zusätzliche Datenfelder hat,
 * es nach dem Bootsektor einen zweiten Sektor mit Systeminformationen gibt
 * das Root-Verzeichnis nicht fest allokiert ist, sondern auch wie eine
   Datei verwaltet wird
 * und die FAT natürlich 32bit-Einträge hat (anstatt 12 oder 16)

Jedenfalls bleiben nach Deinem Vortrag also nur die Verzeichniseinträge und die dazugehörigen langen Dateinamen zurück, die ja nach Lesen der MS-Spec auf in UTF-8 vorliegen können, ...

Nein. Wenn Microsoft in irgendwelchen Windows-Interna von Unicode redet, dann ist das immer UTF-16. Merkt man auch, wenn man sich die entsprechenden Datenstrukturen mal im Hex-Editor anschaut: Da sieht man immer ein ASCII-Zeichen und ein Nullbyte im Wechsel, entsprechend der UTF-16-Darstellung.

und daher bei einer effektiven Länge von 255 Zeichen (das habe ich jeztzt nicht genau nachgeschaut, ob es denn nur 248 sind) durchaus 1kByte Speicherplatz belegen können...

Wir wollen mal nicht übertreiben. ;-)
Die maximale Länge ist 255 Zeichen, siehe Seite 29 der Spec. Da 13 Zeichen pro Directory-Record gespeichert werden können, ergibt das maximal 255/13 Records, aufgerundet sind das 20. Einer kommt noch dazu für den Shortname-Eintrag, macht also "allermaximalstens" 672 Byte für einen vollständigen Verzeichniseintrag. Immerhin, auch schon eine Menge Holz.

Da ich TEMPNAM() benutzt habe mit Präfix "check_" könnte das schon ein Grund für eine Zeitverzögerung sein. Allerdings nicht für die derartig merkliche. Das muss noch einen anderen Grund haben. Den find ich aber auch noch :-))

Ich hoffe es doch und bin gespannt.

So long,
 Martin

[Tom]

Hello Martin,

Wir wollen mal nicht übertreiben. ;-)
Die maximale Länge ist 255 Zeichen, siehe Seite 29 der Spec. Da 13 Zeichen pro Directory-Record gespeichert werden können, ergibt das maximal 255/13 Records, aufgerundet sind das 20. Einer kommt noch dazu für den Shortname-Eintrag, macht also "allermaximalstens" 672 Byte für einen vollständigen Verzeichniseintrag. Immerhin, auch schon eine Menge Holz.

Da ich TEMPNAM() benutzt habe mit Präfix "check_" könnte das schon ein Grund für eine Zeitverzögerung sein. Allerdings nicht für die derartig merkliche. Das muss noch einen anderen Grund haben. Den find ich aber auch noch :-))

Ich hoffe es doch und bin gespannt.

Ich bin nur erstaunt, wie man sich bei intensiver Verwendung einer Hochsprache, die bei oberflächlicher Betrachtung keinerlei Probleme macht (also fast keine *g*), doch wieder so tief in die Annalen eingraben muss und all sein bereits verschüttetes Wissen wieder hervorkramen muss...

Es ist mMn also nicht verkehrt, wenn auch heutige Programmierer noch lernen, was "da unten" passiert. Und ich muss es einfach wieder vorkramen.

Harzliche Grüße vom Berg
http://www.annerschbarrich.de

Tom

[Sven Rautenberg]

Moin!

ich habe hier veraschiedene Threads zu Spezialfragen des gesamtem Problems gehabt die letzten Tage, und im Dialog mit den kritischen Könnern auch so einiges richten können.

Beständige Doppelpostings, die nicht geahndet wurden. Warum eigentlich nicht? Durch dieses fortwährende Detailproblematisieren ist der Blick fürs Gesamtsystem garnicht erst entstanden. Und du laborierst noch immer an Dingen herum, die ich mit dem bisherigen Informationsstand als untauglich bezeichnen würde.

Durch das erstellte Tool werden in der Produktion später bis zu 10.000 Files gegeneinander abgeglichen, ob sie denselben Inhalt haben und ihre im Fileheader befindlichen Metadaten abgestimmt.

Es geht doch offensichtlich um Musikdateien.

Musikdateien haben das Problem, dass sie "gleichen Inhalts" sein können, obwohl die MD5-Prüfsumme unterschiedlich ist.

Das geht ganz einfach: Ein MP3 mit 193 kBit/s und eines mit 128 kBit/s sind von der codierten Musik identisch, aber vom MD5-Hash nicht.

Oder noch schlimmer: Ein MP3 mit ID3 V1.0-Tag und ein MP3 mit denselben MP3-Daten, aber editiertem ID3 V1.0-Tag und eines mit immer noch denselben MP3-Daten, aber ID3 V2.0-Tag zusätzlich.

Allein die Möglichkeit, dass diskritische Zeichen oder sonstige "spannende" Tippfehler in alternativen Dateiversionen unterschiedlich bzw. korrigiert sein könnten (auch überflüssige UPPERCASE oder Leerzeichen), versaut dir jegliche MD5-Sinnhaftigkeit.

Und dann ist danach zu fragen, welche Konsequenz die Entdeckung eines Duplikats hat. Behalten? Warum? Löschen? Warum nicht?

- Sven Rautenberg

[Fabian Transchel]

Hallo Sven Rautenberg,

Allein die Möglichkeit, dass diskritische Zeichen oder sonstige "spannende" Tippfehler in alternativen Dateiversionen unterschiedlich bzw. korrigiert sein könnten (auch überflüssige UPPERCASE oder Leerzeichen), versaut dir jegliche MD5-Sinnhaftigkeit.

Und dann ist danach zu fragen, welche Konsequenz die Entdeckung eines Duplikats hat. Behalten? Warum? Löschen? Warum nicht?

Da hilft es nichts, die Files in eine Liste auszugeben und gegeneinander abzugleichen... einfach löschen würde für mich also ausscheiden :)

Grüße aus Barsinghausen,
Fabian

[Der Martin]

Hallo Sven,

Musikdateien haben das Problem, dass sie "gleichen Inhalts" sein können, obwohl die MD5-Prüfsumme unterschiedlich ist.
[Bitrate] [ID3-Tags] [...]

das ist natürlich völlig richtig. Und die Beispiele ließen sich beliebig fortsetzen: Das eine mp3-Stück hat vielleicht noch 2s Beinahe-Stille am Anfang; bei einem wurde der Pegel angepasst; ...
Es wäre daher wirklich nützlich, wenn es ein Tool gäbe, das klangliche Ähnlichkeiten von Audiodateien bewerten kann.

Für Bilddateien bin ich gerade dabei, Kriterien und algorithmische Ansätze zu sammeln, mit denen Bilder auf "beinahe gleichen" Inhalt überprüft werden können. Dabei sollen dann durch statistische Verfahren Effekte wie Skalierung, Unterschiese in der Gesamt-Helligkeit, ein eventueller Farbstich oder unterschiedliche (Un)schärfe aus der Bewertung rausfallen. Vielleicht wird ja mal was draus. ;-)

Oder noch schlimmer: Ein MP3 mit ID3 V1.0-Tag und ein MP3 mit denselben MP3-Daten, aber editiertem ID3 V1.0-Tag und eines mit immer noch denselben MP3-Daten, aber ID3 V2.0-Tag zusätzlich.

Das würde ich ausschließen wollen, indem ein Tool, das speziell zum Vergleich von mp3-Dateien dient, die ID3-Tags von vornherein ignoriert (da ich die sowieso meistens lösche, würde sich das Problem bei mir gar nicht ergeben).

Und dann ist danach zu fragen, welche Konsequenz die Entdeckung eines Duplikats hat. Behalten? Warum? Löschen? Warum nicht?

Automatisch: Gar keine Maßnahme ergreifen, nur Ähnlichkeiten auflisten. Ich stelle mir als Resultat eine Liste der bearbeiteten Dateien vor, in der als ähnlich erkannte Dateien zusammen gruppiert sind, evtl. mit einer numerischen Angabe, die auf die Ähnlichkeit schließen lässt (z.B. "98.4% match"). Dann kann ich mir die Dateien innerhalb der Gruppe(n) gezielt ansehen oder anhören und selbst entscheiden, welche ich löschen möchte und welche nicht.

Schönen Sonntag noch,
 Martin

[Fabian Transchel]

Hallo Tom,

Bei den (Win)DOSen hilt da nur ein "Verzeichnis umkopieren" oder ein Defrag.

ACK.

Langer Rede kurze Frage:

Wie sieht das bei Linux-Filesystemen wie z.B. ext2 oder
  reiserFS aus?

ReiserFS (Version 4, wenn du dir eine einjährige Version als stabil anzusehen zutraust ^^) ist ein heißer Kandidat für kleine Files (1 - 8 KB), aber ich weiß freilich nicht, was für Files du da herumschubst. Wenn es, so wie Sven argwöhnte, Musikdatein sind, dann dürfte das FS m.E.[1] eine untergeordnete Rolle spielen, hauptsache ist du hast viel Speicher um ordentlich Plattenaktivitäten zu cachen. Ausserdem: Nur Versuch macht kluch :) Nimm ein paar Dateien und kopier sie testweise auf dem Linux-Rechner herum, so wie es dein Algorithmus auch tun würde und schau, wie die Performanz sich verhält.

[1] Freilich solltest du auf jedenfall ein journaling System benutzen, also ext3 oder eben besser ein Reiser4.

Grüße aus Barsinghausen,
Fabian