Probleme mit mehr als 1996 "descript.ion"

[tannoy]

Hallo zusammen,

zu dem Problem, welches ich im Thread "TC beendet sich nach bestimmten Tastenkürzeln" schilderte, gesellt sich noch ein anderes Problem:

(Dieses Verhalten ist aber so alt, wie der TC die "descript.ion" überhaupt kennt. Zumindest bei mir...)

Ich habe einige Verzeichnisse mit ca 40.000 bis 78.000(!) Dateien (Ich kann nichts dafür! Diese LOGs werden werden von SUN exakt so ausgegeben...).
Deren Kommentare werden in dieser "descript.ion" zusammengefasst. Wird in diesem Verzeichnis irgedetwas getan, also etwas hinein oder heraus verschoben (bzw. kopiert), dauern solche Aktionen bis zu 2 1/2(!!!) Stunden!

Ich bemerkte irgendwann, dass die Schallgrenze bei etwa 1990 bis 1996 Kommentaren(bzw. Files mit Kommentaren) liegt. Sind es mehr bricht die Arbeitgeschwindigkeit radikal zusammen.

Meine Abhilfe:
Die Datei "descript.ion" irgendwohin verSCHIEBEN. Alle dateien aus besagtem Verzeichnis in kleinere Verzeichnisse auftrennen (<1996). In jedes dieser Verzeichnisse die "descript.ion" wieder hereinKOPIEREN. Nun für alle diese Verzeichnisse einzeln folgen Aktionen durchführen: Diese Dateien in ein TEMP-Verzeichniss verschieben. Die übriggebliebene "descript.ion"-Datei löschen. Dateien wieder zurückverschieben!
Et voilà: Alle Dateien haben ihren Kommentar und man kann wieder Full-Speed darin arbeiten...

Woran liegt dieser Zusammenbruch der Arbeitsgeschwindigkeit?
Gibt es Abhilfe (zB irgendeinen Cache vergrößern)?

Ich habe mich zwar an dieses Verhalten gewöhnt, aber dessen Erklärung würde mich trotzdem mal interessieren.

Besten Dank

tannoy

PS: Entweder suche ich falsch oder es gab wirklich noch keinen Eintrag zu diesem Problem im Forum.

[icfu]

Ich kann das hier nicht reproduzieren. Habe mir ein Verzeichnis angelegt mit 2000 Dateien und Kommentaren zu 2000 Dateien und stelle keine Performanceprobleme fest, wenn ich eine Datei aus dem Verzeichnis verschiebe und die descript.ion upgedatet wird.

Ist der Datenträger NTFS-formatiert? Falls nein, nachholen!
NTFS verliert im Gegensatz zu FAT/FAT32 mit zunehmender Verzeichnisgröße nicht an Geschwindigkeit.

Evtl. ist auch nicht die Anzahl das Problem bei Dir sondern die Gesamtgröße der Kommentare und Dateien, "1990-1996" ist ja doch eher zu schwammig, als daß es für eine hartkodierte Grenze sprechen würde.

Kurzum, mehr Input bitte:
Wie groß sind die Dateien, Kommentare, descript.ion?
Wie ist der Datenträger formatiert? Clustergröße?
Defragmentierst Du regelmäßig oder ist das Ding eine fragmentierte Wüste?

Icfu

[tannoy]

@icfu
DANKE,

hier die weiteren Angaben (zu Deinen Fragen):

1. Größe: variiert von 0 Bytes (wenn nichts im LOG verzeichnet wurde) bis hin zu einigen MBytes
2. Datenträger: NTFS (V5.0 (WinXP-Pro)), Clustergröße Standard (also 4096)
3. Defrag: HIER: Nicht nötig! (da per Script die HD zuerst formatiert(!), dann erst die Daten gezogen werden!)
Ansonsten gilt: Natürlich defragmentiert!
4.

Evtl. ist auch nicht die Anzahl das Problem bei Dir sondern die Gesamtgröße der Kommentare und Dateien, "1990-1996" ist ja doch eher zu schwammig, als daß es für eine hartkodierte Grenze sprechen würde.

Ich gebe Dir völlig recht. Aber es ist ein Wert, der sich im Laufe der Zeit bei MIR so heraus kristallisierte.

Das, was Du da über NTFS sagt, ist mir bekannt. Das Problem liegt auch nicht an der wöchentlich auftretenden Flut an Dateien. Wie Du ja schon einräumtest: Das macht NTFS nichts aus.

(Bei mir raunten einige Kollegen auch so Schlagworte wie: MFT, ACLs, ...! Das kann es aber nicht sein. MFT- und ACL-Fehler haben mit descript.ion nichts zu tun. Auch META-Streams sind hier nicht involviert! Im Gegenteil, ich hätte ja dann sogar mit "nackten" Dateien ja auch schon solche Probleme.)

Um das Problem nochmals zu fokussieren:
Dieses Problem tritt erst auf, wenn diese Dateien eine "descript.ion" mitbringen. Ohne Kommentare kann ich mit Full-Speed im Verzeichnis arbeiten.

Achso: Aus lauter Frust testete ich damals auch unsinnige Dinge:
- Die Festplatte ist auch in Ordnung! Es ist aber auch von der Platte unabhängig. Alle Platten, die ich ausprobierte, zeigen dieses Verhalten.
- RAM ebenfalls in Ordung (Problem exakt dasselbe auf mehreren Rechnern, auch bei mir zu Hause!)
- Diverse TC Versionen: Alle das gleiche Phänomen. (Zu Zeit neueste Version: 6.03a)

Ich vermute, dass der TC Probleme damit hat, die zugehörige Zeile der zu verschiebenden Datei auf Anhieb in der descript.ion zu finden?

tannoy

[icfu]

Hast Du einen Virenscanner als AV-Monitor laufen? Testweise deaktivieren, ggf. ion-Dateien vom Monitoring ausschließen, empfiehlt sich z.B. bei Kaspersky.

Wie sind Deine Einstellungen in der Konfiguration bzgl. Kopieren/Löschen? Kompatibilitätsmodus mal ausprobiert bzw. Explorermethode?

Daß der TC Probleme hat, die Zeile zu finden bezweifle ich mal, bei 2000 Kommentaren wird die descript.ion ja keine biblischen Ausmaße haben.

Du kannst Dir auch mal den Filemon runterladen und mitloggen, auf welche Dateien der TC zugreift, wenn er hängt, evtl. kommst Du dem Problem dadurch auf die Schliche, wenn Du es mit einem Log einer Operation im Verzeichnis mit <1996 Dateien vergleichst.

Icfu

[tannoy]

@icfu
DANKE,

- bei mir zu Hause hänge ich hinter einem (auf Router zurecht-"kastrierten") Linux-Router der auch auf Viren scannt. Daher -> KEIN Scanner aktiv, zumindest als Dienst! On Demand ist aber rudimentär vorhanden...

- Löschmethode, ähnlich dem zweiten Thread, leider nicht von Belang. Bedenke bitte, dieses Verhalten habe ich auch beim kopieren, bzw. verschieben...

- Filemon hatte ich damals schon zu Rate gezogen, zeigte aber damals wie auch gerade eben, nach Deinem Hinweis, keinerlei Auffälligkeiten:
Zugriff nur auf descript.ion, bzw. GAR KEIN Zugriff auf irgendetwas?!

Allgemein gesagt kann ich auch behaupten ein (relativ) "sauberes" System zu haben, denn ich bin kein Ausprobierer von irgendwelcher "wilder" Shareware oder sonst üblichem Quatsch. Ohne Jemandem nahe treten zu wollen (es ist auch bestimmt nicht böse gemeint!!!), aber "ich habe das Alter erreicht", da muss ich keine Experimente mehr starten. Dieses hier ist ein reines Arbeitstier, daher auch meine Verwunderung dem Ganzen hier gegenüber.
Ich hoffe das kommt jetzt nicht allzu altbacken rüber!

/*
Im Übrigen fällt mir gerade etwas auf, nachdem auch inzwischen eine Mail dazu eintraf:
Es tut mir leid wenn ich hier alle auf die falsche Fährte locke...
(Vielleicht drücke ich mich missverständlich aus, wenn dem so ist liegt das an meiner Erdnuss zwischen den Ohren!)

Also, der Rechner stoppt NICHT!!!

Treffender ist es so zu beschreiben:

Beispielsweise in einem Verzeichnis mit 50000 Dateien, aus dem z.B. 100 verschoben werden, braucht der Rechner INSGESAMT ca. ZWEI Stunden und NICHT für jede Datei zwei Stunden.
Wenn dem so wäre, wäre der Rechner schon lange aus dem Fenster...
(Und: NEIN, es lohnt sich nicht, unten zu stehen und zu warten... (für Profis vielleicht schon!))

Tut mir leid, mein Fehler...
*/

tannoy

PS: Woher hat dieser Jemand, der nicht hier Mitglied ist, meine Email-Adresse???

[icfu]

- Löschmethode, ähnlich dem zweiten Thread, leider nicht von Belang. Bedenke bitte, dieses Verhalten habe ich auch beim kopieren, bzw. verschieben...

Genau davon sprach ich auch, schau doch bitte mal in die Optionen. Die Löschmethode ist nur einer von mehreren Optionen auf dem Karteireiter Kopieren/Löschen.

- Filemon hatte ich damals schon zu Rate gezogen, zeigte aber damals wie auch gerade eben, nach Deinem Hinweis, keinerlei Auffälligkeiten:
Zugriff nur auf descript.ion, bzw. GAR KEIN Zugriff auf irgendetwas?!

Wenn Du einen Filter auf totalcmd.exe gesetzt hast und NICHTS siehst, bedeutet das, daß der TC hängt. In diesem Fall ist die Fehlerursache ein anderes Programm. Wie schaut's denn mit der explorer.exe aus? Geht die in Richtung 100% CPU-Last? Was sagt der Taskmanager, wenn das Problem auftaucht?

Es tut mir leid wenn ich hier alle auf die falsche Fährte locke...

Nö, ich habe Dich schon richtig verstanden, keine Sorge...

Also, der Rechner stoppt NICHT!!!

Na gut, aber irgendwas wird er in den 2,5 Stunden schon machen. Wenn die Dateien zwischen 0 und 5MB groß sind, sollte eine Verschiebeaktion von 100 Dateien in ca. einer Minute fertig sein.

Treffender ist es so zu beschreiben:

Beispielsweise in einem Verzeichnis mit 50000 Dateien, aus dem z.B. 100 verschoben werden, braucht der Rechner INSGESAMT ca. ZWEI Stunden und NICHT für jede Datei zwei Stunden.

Hatte ich auch so verstanden.

PS: Woher hat dieser Jemand, der nicht hier Mitglied ist, meine Email-Adresse???

Sicherlich nicht von hier, Du hast Deine Emailadresse nicht angegeben.

Icfu

[ghisler(Author)]

Also ich würde auch mal mit Filemon untersuchen, wo so viel Zeit verloren geht, das ist auf jeden Fall nicht normal. Filemon zeigt ja den Zeitpunkt der Dateizugriffe an, daran sollte man erkennen können, wo das Problem liegt.