Windows struikelt over hoeveelheid bestanden(38miljoen)

[ETH0.1]

Ik heb een 2012r2 server met een data disk van 800gb waarop 38 miljoen kleine tekstfiles staan (log bestanden van edi transacties). Ik ben er inmiddels achter dat dit probleem zich niet alleen voordoet in 2012, maar ook windows 10, dus een generiek probleem met Windows (ntfs?)

Aanleiding is dat onze backup software zowat weigert om een backup te maken van deze VM, de job komt gewoon niet van de grond, op basis daarvan heb ik de disk geprobeerd onder windows 2016 en windows 10, in alle gevallen heb ik het zelfde probleem.

Vervolgens heb ik een disk scan geprobeerd, deze scan duurt ongeveer 20 uur (erg langzaam) en brengt geen fouten aan het licht. Ik probeer nu een software raid te bouwen van die 800gb disk, dat proces is na 12 uur pas 25% gereed, ook dat schiet dus voor geen meter op.

Zou een ander FS een oplossing kunnen zijn? data migreren naar ReFS bijvoorbeeld, heeft iemand daar ervaring mee?

[hellfighter87]

Ik zou ze zippen, zip per dag/week/maand met welke het beste uitkomt.


Even.aangenomen dat je niet 24/7 acces nodig hebt tot.alle files

Als je er wat meer tijd in wil steken lees je die bestanden dagelijks uit en zet je ze in een NoSQL database.

Ik denk dat je het vooral moet zoeken in het verlagen van het aantal files

Short term: hd vervangen door ssd? Geen idee of dat helpt

[ Voor 48% gewijzigd door hellfighter87 op 08-01-2021 10:54 ]

[Thralas]

ETH0.1 schreef op vrijdag 8 januari 2021 @ 10:43:
Aanleiding is dat onze backup software zowat weigert om een backup te maken van deze VM, de job komt gewoon niet van de grond,

Lijkt me een file based backup dan?

Zoja, is een makkelijke oplossing dan niet om de hele volume block based te backuppen? Zeker met VMs is dat sowieso een stuk flexibeler..

[ETH0.1]

Thralas schreef op vrijdag 8 januari 2021 @ 12:06:
[...]


Lijkt me een file based backup dan?

Zoja, is een makkelijke oplossing dan niet om de hele volume block based te backuppen? Zeker met VMs is dat sowieso een stuk flexibeler..

Dat is hoe we backups maken block level, maar commvault denkt daar blijkbaar anders over. Ondanks dat er niets qua indexing aan staat lijkt commvault hangt commvault er toch op

[keur0000]

Of je maakt directories aan op basis van bijv jaar/maand en verplaats ze in de desbetreffende dir's.
- 202001
- 202002
enz.
Even wat werk maar daarna loopt de boel weer

[iamerwin]

keur0000 schreef op vrijdag 8 januari 2021 @ 12:42:
Of je maakt directories aan op basis van bijv jaar/maand en verplaats ze in de desbetreffende dir's.
- 202001
- 202002
enz.
Even wat werk maar daarna loopt de boel weer

ETH0.1 schreef op vrijdag 8 januari 2021 @ 10:43:
38 miljoen

[RobIII]

Staan alle 38 miljoen bestanden in dezelfde directory? Of heb je daar nog wel een onderverdeling in?

Verder 100% eens met @hellfighter87

[ Voor 16% gewijzigd door RobIII op 08-01-2021 12:47 ]

[F_J_K]

38 miljoen is minder dan 1% van het max aantal files per NTFS directory. Maar inderdaad, zie @hellfighter87

[_Apache_]

Zippen / en weer lezen beperkt je wel in het kunnen inzien van de files. Als dat geen bezwaar is, zou ik het zo doen.

Kijk eens kritisch naar welke data echt relevant is, ouder dan xxx jaar oud niet weg verplaatsen naar een archief server?

[ Voor 44% gewijzigd door _Apache_ op 08-01-2021 12:55 ]

[jeroen3]

ETH0.1 schreef op vrijdag 8 januari 2021 @ 10:43:
Ik probeer nu een software raid te bouwen van die 800gb disk, dat proces is na 12 uur pas 25% gereed, ook dat schiet dus voor geen meter op.

Is de disk niet stiekem kapot?

[vso]

@ETH0.1

stap 1
for each "file" in e:\<folder>
get "creation date" (bv 11-09-2010)
if --"year-month" not excist create "year-month.zip" (2010-09.zip)
do "move into year-month.zip"

Dit duurt het langst ..

maar je reduceert de files van per dag naar maanden per jaar.

stap 2 je kan met een kleine aanpassing het script over de maanden om jaar zips te krijgen ..

het reduceren van de aantal files is nodig zodat windows,chkdisk,backup oplossingen en andere meuk zich simpel weg verstikt ..

---

alternatief is elk bestand zoals hierboven beschreven te "streamen" naar 1 tekst bestand of database maar probleem is dat je elke regel dan wilt voorzien van een datum/index .. dit maakt het meteen complexer

dus zippen is het beste alternatief

Het probleem is dat je backup/windows zich verstikt in het aantal en de wijze waarop windows werkt is "vooraf nadenken" om een tijds indicatie te geven .. dat wil je vermijden in dit geval.

chckdisk --> https://docs.microsoft.co...n/windows-commands/chkdsk
moet je de disk offline (kunnen) halen. maar veel impact zal het wellicht neit hebben

---

ik bedacht net dat je ook \\server\e$\<map>\ (als E:\map\ de locatie is v.d bestanden) en dan op een andere windows/linux server de move2zip actie uitvoeren dit bypassed met grote kans de interne os vertraging .. alleen creeert wel een netwerk load op die machine(s) maar kans is groter dat dit snel gebeurt.

maar ik zou dit zoiezo commandline (powershell /cmd uitvoeren niet via de gui bestanden in een zip "moven"

[ Voor 20% gewijzigd door vso op 08-01-2021 13:11 ]

[Thralas]

ETH0.1 schreef op vrijdag 8 januari 2021 @ 12:36:
Dat is hoe we backups maken block level, maar commvault denkt daar blijkbaar anders over. Ondanks dat er niets qua indexing aan staat lijkt commvault hangt commvault er toch op

Dan is het aantal files toch helemaal niet relevant lijkt me, want block based backup.

Heb je niet gewoon last van een storage layer die het niet meer kan bijbenen?

[Brahiewahiewa]

F_J_K schreef op vrijdag 8 januari 2021 @ 12:50:
38 miljoen is minder dan 1% van het max aantal files per NTFS directory. Maar inderdaad, zie @hellfighter87

https://www.ntfs.com/ntfs-mft.htm
Een optimalisatie van NTFS is dat een file kleiner dan 512 bytes, rechtstreeks in de MFT geplaatst wordt.
Maar bij een aantal van 38 miljoen, gaat dat waarschijnlijk stuk
@ETH0.1 is het geen optie om de schijf FAT32 te formatteren? Nee, dus. FAT32 heeft een limiet van 64k files per directory

[ Voor 6% gewijzigd door Brahiewahiewa op 08-01-2021 14:49 . Reden: voortschrijdend inzicht ]

[Wim-Bart]

Het probleem zit inderdaad in het optimaliseren van de MFT. Bij heel veel kleine bestanden worden deze in de MFT opgeslagen. De MFT is eigenlijk een file op zich. Doordat er heel veel bestanden in de MFT zitten in plaats van losse clusters loopt de server gewoon uit zijn geheugen, hij kan niks meer inlezen en gaat swappen wat het traag maakt. Je zou met NTFS registry settings kunnen spelen om het geheugen gebruik te optimaliseren. Aan de andere kant is het misschien tijd om de bestanden in een database onder te brengen als blob objecten.

[ETH0.1]

Zippen zal helaas niet gaan omdat de files vanuit onze as400 aangesproken moeten kunnen worden, er zitten directories bij met 5 miljoen files, dat is een probleem om ze te listen in de verkenner, maar bij het direct aanroepen van de file geeft het geen problemen

ik begrijp uit de posts hierboven dat het geen zin heeft om de files te verhuizen naar de directories omdat de maste file table zo groot blijft als dat hij nu is. Onderbrengen in een database is een langere termijn oplossing, ik kan daar helaas niet zo veel aan bijdrage omdat het niet mijn afdeling betreft. Ik kan enkel aangeven dat deze manier van opslaan voor problemen zorgt

zou het overstappen op ReFS iets kunnen brengen?

[Brahiewahiewa]

ETH0.1 schreef op vrijdag 15 januari 2021 @ 13:28:
...
zou het overstappen op ReFS iets kunnen brengen?

Theoretisch gesproken zou dat beter moeten gaan. Of dat in de praktijk ook zo is, zul je zelf moeten testen
Bijkomend nadeel is dat ReFS nog lang niet af is; Microsoft is nog steeds bezig om allerlei features van NTFS te "porten" naar ReFS. Wil je wel zo'n feitelijk beta product in je productieomgeving?