Dotaz: Zahlcení USB flašky způsobuje zastavení kopírování

[TomasABC32]

Zdravím, už jsem to tady několikrát řešil, ale nikdy to nedošlo ke zdárnému konci. Koupil jsem si novou flašku Kingston 32Gb a znovu naformátoval na fat32 (což asi byla chyba, protože předtím to fungovalo bez sekání). Nyní když kopíruji větší soubor, dojde k zahlcení a kopírování se zastaví třeba na 77% a čeká i třeba 10 minut, než se to prošťouchne a dokopíruje. Slyšel jsem, že se dají nějak nastavi dirty_ratio a dirty_bytes, aby k tomu nedocházelo a kopírovalo se plynule. Víte o tom někdo něco ? Děkuji za rady.

---

---

Odpovědi

[*hole]

Jak zvýšit kvalitu odpovědí:

• nepoužívej otevřené otázky ("Víte o tom někdo něco ?")
• demonstruj vlastní snahu ("našel jsem si že X by mohlo pomoct, ale když nastavím X na Y, tak se to po Z zase zasekne")

Btw nemáš něco zajímavého v mount options? Například "flush"?

[TomasABC32]

díky, našel jsem tento zdroj, kde je to poměrně pěkně popsáno co s tím.

[lertimir]

před 5 lety se to řešilo i tady

[Sten]

Zápisy na flashky se cachují do RAM. Nejspíš v tu chvíli došla volná RAM a kopírování čekalo, až se flushne na flashku, což kvůli její pomalosti trvalo dlouho. dirty_ratio změní jediné, bude se flushovat dřív a ukazatel průběhu bude lépe odpovídat tomu, kolik se již zapsalo, ale bude to trvat pořád stejně dlouho.

[k3dAR]

neni tak uplne pravda, pouzivam:

echo 104857600 > /proc/sys/vm/dirty_background_bytes
echo 209715200 > /proc/sys/vm/dirty_bytes

bez toho se mi s SSD casto zasekne pocitac i kdyz "jen" pracuji s www prohlizecem...
pri kopirovani (bez tohoto nastaveni) se mi zas po chvilce rychlost kopirovani snizi na 10MB/s (at uz z USB, nebo disk na disk, nebo disk=>sit=>disk, i u rotacnich disku)

nevim sice jestli tazateli to pomuze, protoze u kopirovani na USB jde zaroven i o to ze se nezobrazuje realnej prubeh zapisu na zarizeni ale prubeh zapisu do cache... ze to nedelalo u NTFS muze byt tim ze jinak cachuje a/nebo ze obecne ten zapis je pomalejsi, takze nemusi dojit na tento problem...

[TomasABC32]

tak a ja bych to potreboval změnit tak, aby se mi zobrazoval reálný zápis na flasku... Ne do cache.

echo 104857600 > /proc/sys/vm/dirty_background_bytes
echo 209715200 > /proc/sys/vm/dirty_bytes

kontrola :  cat /proc/sys/vm/dirty_background_bytes

ale to mi ted nejak nefunguje... uz nevim jak jsem to spravne nastavoval.

[TomasABC32]

pokud to poustis jako user, nejdriv musis:

sudo -i

(nestaci dat jen sudo pred ty prikazy kvuli tomu presmerovani > )
nebo to lze napsat takto, tim ze presmerovani zajistuje tee samoosobe, lze pouzit sudo pred nim:

echo 104857600 | sudo tee /proc/sys/vm/dirty_background_bytes
echo 209715200 | sudo tee /proc/sys/vm/dirty_bytes

abys videl realnej prubeh, znamena to vypnout cache, coz si myslim brutalne zpomali zapis, musel bys zarizeni dat do /etc/fstab a pridat volbu sync, neco jako:

/dev/sdb1 /media/tomas/flash noauto,noatime,users,sync,umask=111,dmask=000 0 0

misto "sync" by melo jit pouzit "flush", to nezakaze cache, ale lepe ji vyprazdnuje...

[TomasABC32]

tenhle postup uz vypada velmi dobře. Když to zavedu, kopirovani odpovida vice realne podobě. A kam by se to mělo zapsat, aby se to zavedlo pokaždé při startu PC ?

[TomasABC32]

do /etc/sysctl.conf pridat radky (na konec) :

vm.dirty_background_bytes=104857600
vm.dirty_bytes = 209715200

nebo do /etc/rc.local pridat (NAD radek "exit 0") radky:

echo 104857600 > /proc/sys/vm/dirty_background_bytes
echo 209715200 > /proc/sys/vm/dirty_bytes

[TomasABC32]

super, díky moc. Zkusím.

[TomasABC32]

takže ten problém s dirty_bytes není chyba. Je to jen otázka nastavení?

[TomasABC32]

Ano, není to chyba, je to otázka nastavení. Na druhou stranu současné default nastavení je z doby, kdy byly mnohem menší paměti, a poslední době kapacity rostou mnohem rychleji než rychlosti, takže tvůrci distribucí na to mohli i zareagovat Pokud bych nechal default na svém stroji a používal Flashku s rychlostí tak 10-20MB/s tak v nejhorším případě by mě to mohlo zamrznout na 15 minut. na druhou stranu nizké hodnoty mají za následek nižší přenosové rychlosti, záleží na situaci kolik je operační paměti a jaké jsou rychlosti do disku (těch nejrychlejších i těch nejpomalejších).

[Ovocníček]

Flashky a paměťovky není údajně moc dobré přeformátovávat. Ten výchozí formát a rozdělení je údajně často optimalizované tak, aby to sedělo na strukturu flash, bloky, stránky a tak, plus možná i další divočiny okolo NAND. Když to človk přeformátuje sám, tak se ztratí návaznost a data o interní struktuře. Je možné, že teď třeba nejsou správně alignvoané bloky a při zápisu dochází k nějakýmu neoptimálními "write amplification".

[TomasABC32]

no to jsem udělal :( přeformátoval jsem flešku.

[k3dAR]

preformatovanim se nic v rozdeleni nemeni a pokud se pouzije normalni nastroj na rozdeleni kterej uz roky provadi rozumne zarovnani, tak samozrejme nevadi ani znovu vytvoreni tabulky oddilu a vytvoreni oddilu, jinejma slovama to co psal je proste blbost

[TomasABC32]

ja jsem to formatoval pomalu ve windows na fat32...

[k3dAR]

jak sem psal, i kdyby si zrusil oddily, vytvoril znovu a klidne uuplne jinou tabulku oddilu, vytvoril nove a vice oddilu a zfornatoval kazdej jinym filesysyemem, tak je to JEDNO, protoze to ci psal Ovocnicek (krome zarovnani, coz dela kazdej rozumnej spravce disku) je nesmysl

[lertimir]

Myslím, že nemáš pravdu. Tedy alepoň pokud se nezměnilo v levných fleškách něco za poslední 3-4 roky. Před těmi pár lety jsem měl několik přeformátových flešek na Ext3, na některé měl i provozovaný systém a všechny tyto rychle odešly. Flešky mající původní FS drží. Dokonce některá flash nepoužitelná pod Ext3 se po přeformátování na původní FS začasla chovat použitelně a také drží. Takže si pořád myslím že levné flasky nemají žádný management bloků a wear leveling jako to mají SSD disky. Mají přímý zápis do bloků. Což pro normální data nevadí, ale začne s tím mít problém oblast s blokovou alokační strukturou, jako je FAT tabulka u fat32. A v záviíslosti na použitém FS výrobci tuto část posílí (a je to jen nepatrná paměť v poměru ke zbytku) při přeformátování na jiný FS se alokační tabulka dostane mimo, na normální bloky, a vzhledem k tomu že do této části se zapisuje při jakýchkoliv operacích (zápis, mazání) tak ta oblast odejde. Pře standardním FS dle výrobce ne, má dostatek rezervy.

[Josef Kufner]

To by i celkem dávalo smysl. Navíc tomu i pomáhá, že FAT je neskutečně hloupý a díky tomu předvídatelný file systém.

[Peter Golis]

Hlavne FAT nemá cyklicky prepisovateľný žurnál. Otázkou je či tie karty vedia o sebe korektne povedať veľkosť bloku, alebo ju zatajujú a hovoria klasických 512b.

[Sten]

FAT sice nemá cyklicky přepisovaný žurnál, ale téměř vždy zapisuje do prvních volných bloků, které tak cyklicky přepisuje.

[Peter Golis]

Ale to je rádovo menší problém ako staticky alokovaný a cyklicky prepisovaný žurnál.

[k3dAR]

pouzivam par flesek zformatovanejch na ext4, s vice oddilama i s gpt tabulkou, neodesla mi zadna
to co pises muze souviset spis s tim ze jde o smeckovou flasku ktera nezvladne journal... to jestli je nejaka cast zesilena by se dalo overit tim ze udelas GPT, pro jistotu jeste druhej oddil kam das fat a jestli vydrzi mene nez vychozi vyrobcem dodanej fat, podle me by to bylo "stejne", ale chapu ze to zmerit takto ani nejde... :)

[lertimir]

Nevím jaké máš ty flasky, ale já obvykle kupoval ty obyč, od Adata pár kingstonů, většinou ne dráž než nejlevnější cena+10%. A stačí si odolnost jednoduše spočítat: Počet zápisů do NAND bloku je v posledních letech cca 3000-5000 novější jsou horší, což v případě alokační tabulky znamená, že tento počet operací se soubory na mediu (v oblasti, která padne do mazacího bloku, což pro NAND je min 512k buněk, což pro MLC je 128kB a pro 32 bitovou fat je to 32k clusterů) se dosáhne dost brzy, a pak ten blok padne. Ošetřit se to dá jen wearlevelingem, nebo logikou, kdy tyto bloky se udělají z paměti s menší hustotou a větší odolností na zápis.

[k3dAR]

mam Samsung a Sandisk... tvuj vypocet odpovida castejsimu pouziti journalu, ne nevhodnosti prepartisnovani, opravdu by me zajimalo zda vyrobce urcitou cast (pro partitiontable?) zvyhodnuje... sice z me praxe je to jedno, ale v ramci teorie

[lertimir]

Muj výpočet odpovídá alokační struktuře jako má FAT. to není žurnál. Potřebuješ mít někde vytovřenou strukturu, která ti definuje, jaké sektory jsou volné, jaké sektory jsou obsazené a jakým způsobem navazují jednotlivě obsazené sektory na sebe navazují. Nestudoval jsem interní struktury linuxových filesystému, na druhou stranu FAT znám důvěrně, někdy v letech 88-92 jsem dělal rukama různé obnovy. Nějakou alokační strukturu někde musíš prostě mít. FS musí vědět který sektor je volný a jestli ho může použít a označit pak k jakému soupboru patří a jak na sebe navazují.

Jen pro stručné doplnění. FAT nepracuje na sektorech, ale na clusterech, což je sada sektorů třeba 4KB (8 sektoru) nebo 16kB a nebo i 128kB. cluster je elementární alokační jednotka FAT. FAT tabulka je sada buněk, která definuje obsazení clusterů. Velikost buněk podle FAT16,32 tedy nyní obvykle 32 bitové (4bytové), v době kdy jsem s tím pracoval 16 bitové. Každá buňka odpovídá jednomu clusteru a v tabulce jsou seřazeny od 0 do N, kde N je počet clusterů. Hodnota v buňce má v podstatě 3 významy

• Prázdný cluster - už si nepamatuji jaká konkrétní hodnota to byla, tuším 0.
• Next cluster. tedy v případě, kdy soubor je přes více než jeden cluster tak obsahuje číslo clusteru, který k tomuto souboru obsahuje následující data. Tím pádem hodnoty ve FAT tabulce udělají řetízek clusterů postupnou operací next.
• End of file EOF. V případě že kluster je poslední cluster ze souboru je ve FAT opět specialní kód reprezentujícíobsazeno, ale už nic nenavazuje.

Podstatné je si uvědomit, že do této tabulky se zapisuje při každé změně na disku. při smazání se musí zapsat, že clustery jsou volné, při vzniku, rozšíření, přealokování defragmentaci a pod, se zapíšou, že jsou obsazené, a které jsou obsazené. (například při procesu obnovy smazaného souboru s FAT je číslo prvního clusteru součástí adreářové položky, ale čísla dalších clusteru se už odhadují, primárně tak, že pro nefragmentovaný soubor clustery navazují a z adresáře se vezme velikost. pokud je soubor fragmentovaný je problém větší, informace o navazování se již ztratila.) Ve FAT jsou zápisy na micro úrovni (pár zmněných bytů) a pořád na stejném místě. Nedokážu si přestavit se současnou znalostí NAND, že by to bylo schopno fungovat bez nějakého inteligentního posílení. Ale je zbytečné to posilovat jinde než právě v oblasti FAT tabulky, takže jestli tam naperou malou SLC o pár kB tak jim to moc nezdraží. A také si myslím, že alokační strukturu, která určuje, které sektory jsou volné a které obsazené a jak jsou obsazené musí mít každý FS a pravděpodobně ho má každý jinak. A pokud to má mimo HW posílení tak už je jen wear leveling.

[k3dAR]

ocividne FAT rozumis, nicmene me je jasne ze se do FAT(abulky) zapisu pri kazde zmene, porad ale nevim co je pravdy na tom ze by vyrobce pro to tu cast posilil a pri prerozdeleni, pouziti jineho filesystemu by se toto napojeni na (teoreticke) posileni ztratilo :)

[lertimir]

To já fakticky nevím také. Ale při mnohokrát zdokumentované přepisovatelosti NAND mazacího bloku jen asi 3000-5000, řešíš problém, že máš poměrně malou oblast do níž mnohokrát zapisuješ jen pár bytů. A mne nenapadá jiné řešení než ty dvě které se používají. Buď tedy možné zápisy rozprostřeš po celém disku překryvnou logikou, kdy systém a FS fakticky neví, kam píše (wear leveling) a tím si pomůžeš i v tom že pokud se datově bude psát do malých oblastí tak se to rozprostře také. Nebo očekáváš, že zápisy nebudou nijak silné a nebude jich tak moc, aby to zničilo bloky v normálním datovém prostoru a tam necháš bloky natvrdo na místě a ušetříš za kontrolér a logiku, paralelizaci a celej cirkus kolem wear levelingu (u wear levelingu budeš také potřebovat nějaké malé paměti odolné proti mnoha zápisům kde budeš přepisovat struktury, kde se co zrvona přemapovalo), ale budeš potřebovat něco udělat s tohou malou oblastí, kam se pořád píše. Nic jiného mě nenapadá. A je možné, že to už teď není. cena paměti ve 128GB flasce a 128GB SSD disku se už přibližuje hodně a může nastávat to, že obvody wear levelingu jsou natolik levné, protože se vyrábí masově, že nemá cenu u USB flash to řešit jinak. Ale moje flas jsou z doby kdy cena za GB na Flash byla tak 50-60% ceny v SSD disku a to jsem si jist že to řešili jinak. (Podobně u karet do foták, mnoha lidem odcházejí, mám funkční karty i roku 2004 kdy jsem kupoval první zrcadlovku pro šlo přes ně mnoho destíek tisíc fotek a stovky GB a myslím si za to vděčím způsobu používání, kdy na kartu fotím do zaplněnosti 70-90% průběžně kopíruji a pak smáznu prostředky fotáku, nikdy do nich nezapisuje jiný progrma než ten vlastní foták.)