winacker
Goto Top

Anzahl Dateien in einem DIR begrenzt auf ???

Hallo,
eigentlich braucht das Thema den Anker Windows & Linux...:
einer der Entwickler möchte auf einem meiner NAS (QNAP mit schnellem RAID5) für KI Sprachdatenschnipsel erzeugen/ablegen.
Also zerlegt er größere Dateien in kleine wenige kByte große Segmente via Script übers Wochenende.
Am Montag morgen kam das Scipt aber nicht mehr weiter und ein Zugriffsversuch via Windows auf das Verzeichnis endete im Absturz des Explorers.
Der Zugriffsversuch via QNAP-Shell dauerte einige Minuten und es wurden '137.000 von 3.000.000 Dateien angezeigt, mehr kann die Shell nicht.
Ist das 'normal'?

Kommt mir nun das erste Mal unter und der Entwickler hätte jetzt gern eine externe SSD-USB als Alternative statt NAS.
Nur hilft das ..?

Danke Euch

Content-ID: 3780772346

Url: https://administrator.de/contentid/3780772346

Ausgedruckt am: 05.11.2024 um 00:11 Uhr

SlainteMhath
SlainteMhath 29.08.2022 um 11:19:05 Uhr
Goto Top
Moin,

das kommt aufs Filesystem an, das verwendet wird (lässt sich bestimmt der Doku oder Config entnehmen).

NTFS "kann" z.b. 4,294,967,295 Files pro Directory. Ob das dann das OS/die APP auch noch packt ist eine andere Frage face-smile

lg,
Slainte
MirkoKR
MirkoKR 29.08.2022 aktualisiert um 11:58:11 Uhr
Goto Top
Hi

Der Zugriffsversuch via QNAP-Shell dauerte einige Minuten und es wurden '137.000 von 3.000.000 Dateien angezeigt, mehr kann die Shell nicht.
Ist das 'normal'?

Ja, das das auflisten von derart vielen Dateien extrem lange dauert liegt auf der Hand.
Da wird er auch bei ner USB-SSD mit Problemen zu kämpfen haben.

Also zerlegt er größere Dateien in kleine wenige kByte große Segmente via Script übers Wochenende.

Empfehlen wird sich die Zerlegung in mehrere Unterordner, was ja kein großer Akt sein dürfte, das Script anzupassen ...

.

.
TwistedAir
TwistedAir 29.08.2022 aktualisiert um 13:51:29 Uhr
Goto Top
Zitat von @winacker:

Also zerlegt er größere Dateien in kleine wenige kByte große Segmente via Script übers Wochenende.
Am Montag morgen kam das Scipt aber nicht mehr weiter
[...]
Der Zugriffsversuch via QNAP-Shell dauerte einige Minuten und es wurden '137.000 von 3.000.000 Dateien angezeigt, mehr kann die Shell nicht.
[Hervorhebung durch TA]

Das QNAP-NAS dürfte wahrscheinlich unter einem Linux laufen (da kann man jetzt raten, schließlich gibst du dein NAS und die Software-Version nicht an) - da solltest du berücksichtigen, dass die Anzahl der möglichen Dateien nicht nur vom verfügbaren Speicherplatz, sondern auch von den
Inodes abhängen kann (beim ext-Dateisystem; ZFS verwendet keine Inodes): du kannst nicht mehr Dateien abspeichern als Inodes vorhanden sind. Prüfe doch mal auf der Kommandozeile, wie die derzeitige Belegung ist ('df -i'); gerade der Hinweis, dass es genau 3.000.000 Dateien sind, könnte auf eine Inode-Problematik hinweisen.

Generell sollte das Dateisystem und die Ablage darauf zu dem Anwendungsfall "sehr viele kleine Dateien" passen.

Gruß
TA
1Werner1
1Werner1 29.08.2022 um 13:52:08 Uhr
Goto Top
Moin,

eigentlich ist das ja schon seit langen bekannt, das Windows sich sehr schwer mit vielen Dateien in einen Verzeichnis tut.
Aber nach meiner Ansicht, bringen die Vorschläge hier nichts.
Warum arbeitet der Programmierer nicht mit einer Datenbank ?
Er will doch später nicht in 130 000 Dateien auch noch suchen ?

Ich weiss nicht wie das heute ist , aber dann kann man das Montags die Suche anstellen und dann Freitags mal schauen ob er fertig ist.

Schönen Gruß aus dem Emsland

Werner
winacker
winacker 29.08.2022 um 16:07:25 Uhr
Goto Top
DAs Ding ist, das die Audioschnipsel in Tools wie Tensorflow gefüttert werden müssen.
Ich weiß nicht, ob die mit einer DB zurecht kommen...
Es sind übrigens nicht genau 3M Dateien, sondern ein paar Tausend mehr oder weniger, hat also mit der reinen Zahl nix zu tun.
Er will es jetzt mal mit einer extern via USB angeschlossenen SSD unter Linux probieren.
MysticFoxDE
Lösung MysticFoxDE 30.08.2022 aktualisiert um 08:36:08 Uhr
Goto Top
Moin winacker,

Der Zugriffsversuch via QNAP-Shell dauerte einige Minuten und es wurden '137.000 von 3.000.000 Dateien angezeigt, mehr kann die Shell nicht.
Ist das 'normal'?

jain, das kann man bei Windows heutzutage leider nicht zu 100% sagen

Ich schätze, dass dein Problem nicht nur eine Ursache hat.

Zum einen könntest du den SMB Client auf dem Windows Rechner der auf die NAS zugreift, versuchen etwas zu optimieren.

Folgend ein kleiner Vorschlag:

Set-SmbClientConfiguration -DirectoryCacheLifetime 0 -Confirm:$false
Set-SmbClientConfiguration -EnableBandwidthThrottling $false -Confirm:$false
Set-SmbClientConfiguration -FileInfoCacheLifetime 0 -Confirm:$false
Set-SmbClientConfiguration -FileNotFoundCacheLifetime 0 -Confirm:$false
Set-SmbClientConfiguration -WindowSizeThreshold 1 -Confirm:$false
Set-SmbClientConfiguration -ConnectionCountPerRssNetworkInterface 1 -Confirm:$false
Set-SmbClientConfiguration -MaxCmds 32768 -Confirm:$false
Set-SmbClientConfiguration -EnableSecuritySignature $true -Confirm:$false
Set-SmbClientConfiguration -RequireSecuritySignature $false -Confirm:$false

Mit dem folgenden Befehl kannst du die oberen Änderungen übrigens jederzeit wieder auf Standard setzen.

Reset-SmbClientConfiguration -All

Dein zweites Problem wird wahrscheinlich die auf der Windows-Workstation per default sehr suboptimal konfigurierte Netzwerkkarte sein.
Kannst du auf der Workstation mal den folgenden Befehl durchjagen

Get-NetAdapterAdvancedProperty | FT -AutoSize

und dessen Ausgabe hier posten.

Das dritte ist wahrscheinlich das Windows-Softwarecaching, welches den IO zwischen dem NAS und der Workstation ständig und meistens unnütz über deren RAM zieht und diesen dadurch recht einfach "vollballern" kann.
Das ist jedoch ein sehr schwierigste Thema und nicht mal so kurz zu erläutern.
Ich habe mir an dem Thema schon den einen oder anderen Zahn an Microsoft geschrottet. 😭
In dem folgenden Beitrag sind diesem Problem schon diverseste Posts gewidmet.
So, ab hier, aber auch vorher wird es schon mehrfach angesprochen.
https://community.spiceworks.com/topic/post/9003716

Ja, in dem Post geht es meisten um das "Block-Device-Caching", das Verhalten von Windows ist bei Dateizugriffen über SMB jedoch nicht viel anders, weil hier ähnlich gecacht wird.

Beste Grüsse aus BaWü
Alex
holli.zimmi
holli.zimmi 30.08.2022 um 12:28:34 Uhr
Goto Top
Hi,

der Workaround wäre eine virtulle "xxxx.vhdx" anzulegen mit NTFS formatiert am NAS und diese freigeben.
Wir hatten auch so ein problem mit einem Windows-server 2012 und haben dies damit umgangen.

Gruß

Holli
1Werner1
Lösung 1Werner1 30.08.2022 um 13:19:30 Uhr
Goto Top
Zitat von @winacker:

DAs Ding ist, das die Audioschnipsel in Tools wie Tensorflow gefüttert werden müssen.
Ich weiß nicht, ob die mit einer DB zurecht kommen...
Es sind übrigens nicht genau 3M Dateien, sondern ein paar Tausend mehr oder weniger, hat also mit der reinen Zahl nix zu tun.
Er will es jetzt mal mit einer extern via USB angeschlossenen SSD unter Linux probieren.

Moin,

habe mal bei Wikipedia nachgeschaut:

Bei Partition mit ext2 z.B:

Das Dateisystem begrenzt die Anzahl von Unterverzeichnissen in einem gegebenen Verzeichnis auf 32.000 Stück. Weiterhin wird angewarnt, wenn in einem Verzeichnis mehr als etwa 10.000 bis 15.000 Dateien liegen, dass Dateioperationen in solch großen Verzeichnissen lange dauern könnten.

Ich denke du wirst mit deiner Lösung nicht glücklich .

Ich denke du muss da ein System entwickeln ähnlich wie ein Dokumentenmanagement System.
Du muss deine Schnitzel katalogisieren, das heißt eine Datenbank erstellen aus dem Tensorflow weiß,
wo er welchen Schnitzel findet, vielleicht nach Tonart, Länge usw.
Dann wär es egal in welchen Verzeichnissen du deine Schnitzel hast.


Schönen Gruß aus dem Emsland

Werner
winacker
Lösung winacker 31.08.2022 um 09:08:47 Uhr
Goto Top
Vielen Dank für Eure Beiträge; speziell MysticFoxDE hat ja sehr ausführlich versucht das SMB zu optimieren.
Habe die Patches auch mal angewendet, leider ohne sichtbaren Erfolg. Ich möchte das auch nicht weiter treiben, sondern werde die Leute anweisen einfach weniger Dateien/Verzeichnis zu verwenden - oder aber wirklich auf eine DB zu schwenken.
Also wie immer bei MS - wenn der eine Weg nicht geht, nicht zu lange Zeit drauf verwenden warum die reine Lehre nicht tut sondern einen Workaround bauen.

Jetzt muß ich erstmal diese Leichenverzeichnisse eingebnet kriegen ... face-sad