9
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
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
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 3780772346
Url: https://administrator.de/contentid/3780772346
Ausgedruckt am: 21.11.2024 um 12:11 Uhr
9 Kommentare
Neuester Kommentar
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
lg,
Slainte
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
lg,
Slainte
Hi
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.
Empfehlen wird sich die Zerlegung in mehrere Unterordner, was ja kein großer Akt sein dürfte, das Script anzupassen ...
.
.
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'?
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 ...
.
.
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]
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
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
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
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.
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 winacker,
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:
Mit dem folgenden Befehl kannst du die oberen Änderungen übrigens jederzeit wieder auf Standard setzen.
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
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
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'?
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:$falseMit dem folgenden Befehl kannst du die oberen Änderungen übrigens jederzeit wieder auf Standard setzen.
Reset-SmbClientConfiguration -AllDein 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 -AutoSizeund 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
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
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
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.
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
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 ...
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 ...
