Vlákno názorů k článku Záchrana dat ze starého RAID 0 vytvořeného pomocí fakeRAID od [object Object] - Clanek dobry, ale proc v prvnim reseni pouzivas...

Clanek dobry, ale proc v prvnim reseni pouzivas sync a proc rovnou 2x?

Vzdyt kdyby se to mohlo prohodit, tak se na bash nelze spolehnout. Pri spousteni s & za prikazem nebo pri paralelizaci bych prohodeni rozumel i kdyz sync by to nevyresil, ted tomu nerozumim.

tiez som to nepochopil. pokial tam nebude na konci & tak neni dovod aby sa poprehadzovali data

no já bych si tím úplně jist nebyl, dd ve výchozím stavu negarantuje že jsou data zapsány, když skončí

viz man dd: fdatasync - physically write output file data before finishing

To je jedno ci to zapise teraz alebo za minutu ked sa bude flusovat cache. Ale zapisu sa na to miesto, kde sa zapisat malo a nie hocikde.

Jako samozrejme nepocitame s tym ze niekto vytrhne kabel, ze :)

16. 12. 2019, 08:54 editováno autorem komentáře

teď jsem zkusil variantu 1 bez sync a výsledek je sice dobře, ale stejně tomu moc sám nevěřím :)

rychlostně je to pořád o kousek pod variantou 2 a varianta 3 je pořád nejrychlejší

ten sync na fyzicke zapsani ma smysl jen kdyz medium s vysledkem chces realne/fyzicky odpojit (a odnest si od pocitace)

ten sync dvakrát se dříve v dřevních dobách doporučoval, teď to už zřejmě není potřeba, ale ten druhý sync je časově prakticky zadarmo

https://serverfault.com/questions/219187/is-it-really-necessary-to-call-bin-sync-twice-before-an-unmanaged-power-off

Já si tedy také myslím, že data budou zapsána ve správném pořadí i bez sync. Sync by měl pouze zařídit zapsání cache fyzicky na disk. I při nesyncnutých datech bude pořadí správné a budete z disku číst i správná data. Akorát o ně můžete přijít, pokud odpojíte napájení.