Pomalý unzip ve Windows z NAS na SD kartu

[mikesznovu]

2gigový archiv  (inflated 2.5GB)na nasu jsem chtěl v pracovní stanici (z průzkumníku \\sh\sl\x.zip) s windows 10 rozbalit na SD kartu (70MB/s)+ (čili oboustranně nelokální) : CPU Skylake 4jádro. síť tlačí 90MB/s
Proč to jelo 6 MB/s, tedy asi na 26 minut?
Když jsem přes ssh rozbalil soubor na nasu trvalo to asi minutu (disky 240MB/s pro dokreslení a budiž polovina rychlosti když to bylo v rámci jednohodisku) - ale jaký je jas není podstatné, tam bych pomalost nehledal.

Když jsem soubor  kopíroval na  sdkartu (z rozbaleného umístění nasu - ze stejné složky jen zip->exe*) ,jelo to 20MB/s (nevim proč, jestli karta byla unavená nebo interní čtečka je vykopávka) , pro ověření, kopie jiného souboru na plochu jela těch 80MB/s, pro ověření kopie souboru jiného z plochy na sd kartu taky 25MB/s., pro ověření, rozbalení z nasu na plochu 60MB/s - asi na 30 sekund.

Proč je to v windows tak pomalé z nasu na kartu? trvalo by to 26 minut, 6MB/s. Když i vsoučtu rozbalení na armovém nasu trvalo pod minutu a přenos asi necelé 2minuty? I kdyby windows průzkumník nejdřív celý soubor kopíroval to $TEMP, a pak rozbaloval by to taky zabralo max 3 minuty.

Mám pocit, že jsem urobil všechny související testy v před-předchozim odstavci a vypadá to, že" celek je pomalejší než součet částí "

*defendry, crowdstrajky, nortony, kaspersky ani jiný zpomalovače nemám
**jo, teď si uvědomuju, že to není má špičková sd karta na úrovni 80% UHS-1, ale nějaká seškráblá z podlahy linuxdays, ale lowend to není, nějaký A1 nebo V30 sandisk

[Reklama]

[Jan Fikar]

SD karty mají typicky o dost horší random access než sequential access.

[RDa]

Nemas nejaky prechytraly unzip ktery to jede vicevlaknove?

To je dobry na NVMe, nebo SATA SSD, ale pri konkurencnim IO pro SD karty to v minulosti u me vzdy brutalne kleslo (mozna to bude dnes lepsi u A2 s CQE

[jauznevimco]

To jsi jako extrahoval tim vestavenym ZIP nastrojem, co je ve winblows?

Checht...


Historka z nataceni, mel jsem v praci par notasu na test.
Stahnu benchmark, extrahuji 2 GB archiv tim vestavenym unzipem... 400+ vterin na fungl novym zeleze s W11 ( + Defender ATP a nejaka bizuterie).
Tak dumam, co kuci podelali, ze je to tak strasne liny (masina na Intelu to dala treba za polovicni cas, nepodstatne).
Mezitim si rikam, fajn, zkusim to srovnat jeste s dvoujadernou gen7 i7 (NVMe, W10, zadnej Defender) a ctyrjadernou desktopovou i7 (SATA SSD, W10, zadnej Defender). V podstate bez rozdilu.
Pro vylouceni I/O udelam testy na desktopu komplet v RAMdisku. Vysledek je jeste horsi, nez predtim.
Mezitim pise kolega, ze na gen14 i7 (W11 + NVMe + Defender) to mel hotovo za 20 vterin. 20x tak rychle, to prece neni mozny...


Rozuzleni:
7-Zip to mel rozbaleny za ... zhruba tech 15-20 vterin na vsech tech masinach vejs.


Takze... ten wokenni archiver sice nejak funguje, ale vykonnostne je zcela k nicemu. A kdyby nekdo chtel treba v ramci nejakych srovnavacich testu pouzivat powershellovsky Expand-Archive a sledovat jeho cas, tak klidne muze, ale o uzitecnosti takove informace bych se byl ochoten prit.

[𝑾𝑰𝑭𝑻]

Potvrzuji, integrovaný zip ve Windows je pomalý jak šnek, používám jen v krajní nouzi, když nic jiného není, jinak normálně 7Zip, případně integrovanou podporu archivů ve FAR Manageru.

[Reklama]

[Marek Staněk]

On je obecně dost velký rozdíl při zápisu na kartu, jestli to rozbaluješ přímo na ni (a jede to stylem rozablím blok, zapíšu blok, aktualizuju metadata a alokační tabulky, commit zápisu, rozbalím další blok, zapíšu ho, a tak pořád dokola), nebo to rozbalíš někam, a pak na kartu pošleš sekvenčně (alokuju prostor, zapíšu všechna data, aktualizuju metadata a alokační tabulky, commit zápisu).
To první se chová jako random zápis, to druhé jako sekvenční.