13.4.2010 20:04 | x | | poslední úprava: 25.2.2018 21:49

         

Komentáře

[petr_p]

Příčina je v loopu. Souborový systém spravujete na úrovni loopu, ale těch 30 MB zapisujete do obrazu pod loopem. Obsah mezi loopem a obrazem není v Linuxu synchronní. Konkrétní implementační detaily neznám, ale už jsem si toho také všiml. Proto příště provádějte všechny operace do loopu, nebo loop mezi nimi zrušte. Nedeterminismus právě způsobuje bloková cache mezi loopem a obrazem.

[kralyk z abclinuxu]

Aha! Dík moc zavysvětlení.
Když do teho skriptu přidám i odpojování a připojování loop vždy před/po úpravě image, tak už to hlásí shodu haší.

Nevíš, jestli je možný nějak vynutit vysypání cache, aniž by člověk musel odpojovat loop? Používám loop device v programu, a nějaké takové volání by se mi hodilo - asi to bude nějaké to ioctl(), nicméně man 2 ioctl mě moc neosvítilo a ani se strýčkem googlem zatím nemám úspěch...

[Semo]

echo 1 >/proc/sys/vm/drop_caches

[kralyk z abclinuxu]

Obávám se, že tenhle postup nebude tak docela POSIX-comforming... ale stejně díky, protože googlení tohohle příkazu mě přivedlo k funkci sync(), která by, alespoň to tak vypadá, mohla pomoct...

[j]

on existuje i prikaz sync, ktery dela presne to, co potrebujete (tj. vynuti zapsani dat z bufferu do permanentni pameti). Nepotrebujete tu cache vyprazdnit, to muze byt dost kontraproduktivni.

[kralyk z abclinuxu]

I s použitím obojího, jak sync() i fsync() volaného před i po úpravě image nedeterminismus trvá :/

[petr_p]

fsync(2), nebo se podívejte, co dělá blockdev --flushbufs.

Obávám se ale, že tím nevyřešíte opačný směr. Tedy jak dostat změny obrazu do loopu.

[kralyk z abclinuxu]

Počkat, počkat, beru zpět. Teď jsem si všiml, že hash občas nesouhlasí ani když ji odpojim/připojim.
Tzn. s takovýmhle skriptem:

#!/bin/bash

truncate --size 100M img
mkdir mountpoint
dd if=/dev/urandom of=file bs=1024k count=85

# prvni filesystem
losetup /dev/loop7 img
mkfs.ext3 /dev/loop7
mount /dev/loop7 mountpoint
cp file mountpoint/file
umount mountpoint/
losetup -d /dev/loop7
dd if=/dev/zero of=img bs=1024k seek=30 count=30 conv=notrunc 
losetup /dev/loop7 img
fsck.ext3 -p /dev/loop7
mount /dev/loop7 mountpoint/ 
md5sum mountpoint/file > hash
umount mountpoint/
losetup -d /dev/loop7

# druhej filesystem
losetup /dev/loop7 img
mkfs.ext3 /dev/loop7
mount /dev/loop7 mountpoint
cp file mountpoint/file
umount mountpoint/
losetup -d /dev/loop7
dd if=/dev/zero of=img bs=1024k seek=30 count=30 conv=notrunc
losetup /dev/loop7 img
fsck.ext3 -p /dev/loop7
mount /dev/loop7 mountpoint/ 
md5sum -c hash &> vysledek
umount mountpoint/
losetup -d /dev/loop7

rm hash
rm file
rm -r mountpoint
rm img

Mi to stejně občas hazí neshodu.
Hm, to je dost nemilé.

teď si ale vzpomínám, že fdisk po úpravě disků volá nějakou synchronizaci přes ioctl() - nemohlo by mi tohle pomoct? Nevíte někdo, co vom to tam volá?

[kralyk z abclinuxu]

Hm, tak jsem se podíval do zdrojáků fdisku, a volá tam ioctl(fd, BLKRRPART), což je určeno, jak jsem se dočetl, k znovu načtení partition table, což asi nebude tak úplně můj případ...

Mimochodem, nefunguje to ani s echo 1 > /proc/sys/vm/drop_caches. Takže já opravdu nevím... Asi budu muset zapisovat rovnou do loop device, nebo co, to ale budu muset překopat kód... :/

Není mi jasný, jaktože není někde pořádná dokumentace volání ioctl()... taková klíčová funkce systému.

[petr_p]

V ioctl_list(2) se dozvíte hlavičkový soubor a ten najdete ve zdrojácích jádra. Obvykle tam je aspoň nějaký komentář. Jinak si musíte najít zdrojový kód daného IOCTL.

[Heron]

Není to tím, že fsck zapisuje (do supebloku) čas poslední kontroly a také nastaví na nulu počet připojení od poslední kontroly?

[Semo]

To urcite robi, ale oni pustaju md5sum na subor, nie na cely fs.

[kralyk z abclinuxu]

Příloha:

• ext3-nedeterm-paranoia (1195 bytů)

Přesně tak, žádný metadata by v tom být neměly.

V příloze najdete naprosto paranoidní verzi skriptu. Jsou v ní použity všechny zméněné metody na vysypání se cache, navíc přepisuju data ne do image souboru, ale přímo do loop device.
A přitom to stále hlásí neshodu haše. Jestli ona nakonec opravdu nebude chyba v ext3.

Na ty ioctl se ještě taky podívám, díky.

V průběhu dneška tohle ještě vyzkouším na starší flashce, a uvidí se...

[Sinuhet]

Jenze vam do toho nezasahuje jenom fsck, ale i kod, ktery obhospodaruje filesystem. Pokud nahodne prepisete cast filesystemu, tak se vam klidne muze stat, ze fsck do souboru obnovi kdejaky bordel, treba bloky, co byly driv metadaty s timestampou uvnitr.

Pokud chcete testovat jenom fsck, tak musite udelat jeden obraz s 1M nul, nakopirovat si ho a dvakrat na nej spustit opravu filesystemu. Jen tak budete mit jistotu, ze vstupni data pro fsck jsou identicka.

[kralyk z abclinuxu]

Mně nejde o to testovat pouze fsck jako takový, ale celý filesystém.
A ten dostává data indetická. Na začátku vytvořím náhodný soubor. A pak dvakrát vytvořím stejně velký filesystém se stejným nastavením, dvakrát do něj nahraju ten samý sobour, dvakrát ho úplně stejně přepíšu, a pokaždé dostanu z fsck jiný výsledek.

Jestliže úspěšnost/chování mkfs/ext3-driveru/fsck závisí na nějakém timestampu, je něco špatně... No já du hledat tu flashku...

[Sinuhet]

Nedostava identicka data. Minimalne je rozdilny cas, kdy ty operace provadite a AFAIK nikde neni garantovano, ze pri jakemkoliv provedeni stejnych user-level operacich bude obraz filesystemu na disku stejny do posledniho bitu. Pokud neni stejny do posledniho bitu, pak fsck muze dostat jina data a nasledne muze vyhodit jiny vysledek.

[kralyk z abclinuxu]

Obraz filesystému stejný být nemusí, ale obnovená data by měla.
Já to testuju prográmkem, na kterém pracuju (který zatím není veřejně vydán, ale snad časem bude), a když změřím přesně na bajt procento obnovených dat, tak tohle procento u ext3 hodně skáče (až o 10%!) jen v závislosti na čase. Žádný jiný filesystém (včetně ext2 a ext4) tohle nedělá.

Myslím si, že nikomu by se nelíbil fakt, že šance na obnovu jeho dat při nějaké havárii závisí na tom, kdy tam ta data zapsal.

[Heron]

Říkal jsem si k čemu tohle cvičení má být dobré.

Myslím si, že nikomu by se nelíbil fakt, že šance na obnovu jeho dat při nějaké havárii závisí na tom, kdy tam ta data zapsal.

No já myslím, že by měl být rád pokud z takto (přepsání 30% FS nulami není běžné poškození, pevný disk občas nepřečte pár sektorů) poškozeného FS vůbec nějaká data vytáhne, protože tuto funkcionalitu mu nikdo nezaručuje.

[kralyk z abclinuxu]

přepsání 30% FS nulami není běžné poškození,

Například, když člověk spustí dd se špatným of. Nebo když mu nějaký zabugovaný SW přepíše disk. Samozřejmě připouštím, že to není tak docela standardní porucha.

Mi šlo o to, že žádný jiný FS tohle nedělá. Myslim si, že ani za takové situace by filesystem neměl nějaké timestampy brát do úvahy.

Kdyžtak napiš, jak vypadá standardní porucha, potřebuju na tohle téma slyšet pokud možno více názorů

[Heron]

Například, když člověk spustí dd se špatným of. Nebo když mu nějaký zabugovaný SW přepíše disk. Samozřejmě připouštím, že to není tak docela standardní porucha.

Tohle se mi stát, tak si ten fsck pustím jen pro zajímavost a mezitím najdu zálohy. Protože ty soubory na takto přepsaném disku nebudou tak jako tak v pořádku. fsck sice možná dá ten FS dokupy, ale k čemu to je, když těm datům pak nelze věřit?

Mi šlo o to, že žádný jiný FS tohle nedělá. Myslim si, že ani za takové situace by filesystem neměl nějaké timestampy brát do úvahy.

Jasně, narazil jsi na záhadu a pátráš po příčinách, na to nelze nic namítat.

Kdyžtak napiš, jak vypadá standardní porucha, potřebuju na tohle téma slyšet pokud možno více názorů

Nemožnost přečíst jeden (většinou izolovaný, případně malé shluky) sektor, případně více sektorů náhodně rozprostřených po disku. Špatné přečtení sektoru (tj sektor je čitelný ale vrací jiná data než se tam zapsala), se snad díky kontrolním součtům vyskytovat nebudou. Pak mě napadá třeba rozpadlé pole, kdy budou chybět celé stripy.

[kralyk z abclinuxu]

Tohle se mi stát, tak si ten fsck pustím jen pro zajímavost a mezitím najdu zálohy. Protože ty soubory na takto přepsaném disku nebudou tak jako tak v pořádku. fsck sice možná dá ten FS dokupy, ale k čemu to je, když těm datům pak nelze věřit?

Právě že se jim většinou věřit dá, alespoň to tak z mých testů plyne. Relativně malá část souborů na disku jsou "rozházené". Makám na metodice, jak měření "rozházenosti" zlepšit.

Nemožnost přečíst jeden (většinou izolovaný, případně malé shluky) sektor, případně více sektorů náhodně rozprostřených po disku. Špatné přečtení sektoru (tj sektor je čitelný ale vrací jiná data než se tam zapsala), se snad díky kontrolním součtům vyskytovat nebudou. Pak mě napadá třeba rozpadlé pole, kdy budou chybět celé stripy.

Můj prográmek zatím podporuje nastavení toho, co má přepsat, jednak ve formě částí (string jedniček a nul, jednička - přepsat, nula - nechat) - tak se dá nastavit třeba "smaž prostřední třetinu" nebo "smaž druhou a poslední osminu" apod. a jednak můžu přímo specifikovat rozsahy "nehody" odkud pokud v bajtech, takže emulovat ztrátu sektoru(ů) bych tímhle asi mohl... ještě na to kdyžtak kouknu...

[Heron]

Právě že se jim většinou věřit dá, alespoň to tak z mých testů plyne.

No, ale jak poznám, které soubory jsou ty nepoškozené? Jistě, šlo by společně se zálohou dělat hashe souborů na disku, po fsck je zkontrolovat a pak ze zálohy vytáhnout ty poškozené. Což bude narážet na problém, že soubor nemusí být poškozený, ale zapisovalo se do něj po provedení zálohy (tj nebude sedět uložený hash). Obecně to pak lze poznat tak, že otevřu všechno soubory v programech, které s nimi umí zpracovat a takto je zkontroluji.

Relativně malá část souborů na disku jsou "rozházené". Makám na metodice, jak měření "rozházenosti" zlepšit.

Relativně. Pokud přepíšeš 30% FS tak podle náhody může být poškozeno 30% dat nebo taky třeba žádná data, pokud se to "poškození" náhodou trefí do volných bloků.

[kralyk z abclinuxu]

Obecně to pak lze poznat tak, že otevřu všechno soubory v programech, které s nimi umí zpracovat a takto je zkontroluji.

Přesně tak. Jiná možnost, obávám se, není. Já se nezabývám rozpoznáním, který soubor je konzistentní, ale pravděpoboností s jakou je soubor po fsck konzistnení...

[Sinuhet]

Nastroj fsck neni urcen pro obnovu dat, ale pro uvedeni filesystemu do konzistentniho stavu.

Ja nevim, co presne delate, ale jestli merite neco jako odolnost ruznych filesystemu tim, ze do nich nakopirujete soubor a pak vsem na stejnem miste prepisete 30M, tak to neni nejlepsi metodika. Nejspis se vam jenom stalo, ze jste u ext3 vyhmatl hodne nestastnou kombinaci faktoru. Neni zadny problem zapisem na vhodne misto poskodit soubor a fs ani nepozna, ze k necemu doslo.

[kralyk z abclinuxu]

Ja nevim, co presne delate, ale jestli merite neco jako odolnost ruznych filesystemu

Jo, něco takovýho bych rád. Pokud máš nápad na vylepšení metodiky, sem s ním!

Nejspis se vam jenom stalo, ze jste u ext3 vyhmatl hodne nestastnou kombinaci faktoru.

Ale kdepak, ext3 tohle dělá skoro vždycky. Když do něj nakopíruju hafo 10MB souborů a přepíšu poslední šestinu, chová taky takhle. Když změním velikost filesystému na 500MB nebo 4GB nebo víc, pořád to samý.

[kralyk z abclinuxu]

No tak jsem to otestoval na flashi a stejný výsledek.
Máš ale určitě pravdu v tom, že to není jen v samotném fsck (asi), čili zkusím opravit titulek zápisku...

[Semo]

Myslim, ze sa ti snazi naznacit, ze ak poskodis fs, tak fsck netusi, ktory blok patri do ktoreho suboru. Takze ti doprostred suboru namiesto chybajuceho bloku priradi nejaky. Lenze obsah toho bloku asi neprepisuje (v pripade, ze by sa nahodou trafil a priradil spravny strateny blok, tak by asi nebolo dobre jeho obsah znicit). A problem je, ze ak priradi blok, ktory obsahuje nejake casove znacky, tak aj ked ho bude priradovat uplne deterministicky, tak obsah toho bloku bude zalezat na tom, kedy si fsck spustil.

[pht]

Hm, v tom by to mohlo být. Vy totiž přepíšete IMHO i alokační tabulku bloků a fsck už nedá dohromady původní soubor, ale jen prostě veme nějaké bloky aby seděla velikost.

Ty bloky budou mít asi v obou testech různý obsah. Zkuste si dát do file něco smysluplného a uvidíte, jak se jeho obsah bude měnit. Zkuste před oběma testy inicializovat obsah disku nulami a mělo by se to začít chovat "deterministicky".

Nevím jaké další FS testujete ale ext4 používá extenty, tudíž žádnou takovou alokační tabulku bloků nemá. Proto skutečně přepíšete nulami jen ta data.

[kralyk z abclinuxu]

Update: dělají to všecky ext, tedy ext2, ext3 i ext4
A děje se to, i když přepíšu menší část a víc ke konci disku - třeba poslední šestinu. Tam imho alokační tabulka není.

Dále jsem testoval xfs, jfs, reiserfs, btrfs - z nich žádný tuto nedeterminističnost nevykazuje při jakékoli konfiguraci přepsání.

Zajímavé je, že na stejném fs a stejných datech (akorát zapsaných v jiný čas) ext2 při fsck někdy zvolí interaktivní mód a někdy opravuje automaticky

[=^..^= AmigaPower®]

kdo obsahu nerozumí, nechť to nespouští!

Děti, nepijte kyselinu, rozežere vám vnitřnosti...



...kam to mam celý napsat a jak se to spouští pod rootem?

[kralyk z abclinuxu]

No, člověk, který ví co dělá nebo kterému nevadí případná škoda () to uloží do souboru, nastaví tomu souboru právo spustelnosti a spouští příkazem ./soubor z terminálu. To abys neřek, že ti odpírám informace. Ale víš jak se to říká... "s velkou mocí přichází i velká..." hm, teď nevim, bylo tam "zodpovědnost" nebo "sranda"?

[Václav HFechs Švirga]

nebo se da nastaveni tech prav obejit (to je informace pro amigu):

$ su root
$ bash soubor_ktery_ti_zamori_pc_kralyky.sh

delam kdyz se mi nechce nastavovat prava spousteni kdejake kravine :)

[=^..^= AmigaPower®]

kdo obsahu nerozumí, nechť to nespouští!

Jsem zpět! Neni nad čerstvě nainstalovanou Mandrivu

[Václav HFechs Švirga]

ROFL!!! :D Nic moc duchaplnejsiho nenapisu, protoze po pul roce klidu mi zas vali z niceho nic krev z nosu a drzim si kapesnik. Vzdycky to mam jen pres jarni, letni obdobi, zima klid :/.

[=^..^= AmigaPower®]

...ale teď mi nejede zvuk v youtube (FF3.6), tak zas mam kurva tak půl roku s čim si hrát...

[kotyz]

to je v riti, chtel sem ti zrovna poslat odkaz na jeden animac na aktualni tema valeni krve odnekud

bez zvuku to fakt neni ono, ze si ten blbej skript z kralikarny vubec spoustel ...

no jeste muzes zkusit to video stahnout a pustit ho v mplayeru, to mozna zvuk i mit budes ...

[kralyk z abclinuxu]

To si děláš cvičky, tys fakt musel kvůli tomu reinstalovat Mandrivu? To mi nedělej, ještě si to budu vyčítat...

[=^..^= AmigaPower®]

Když je někdo takovej vůl, napíše mi do blogu návod a ještě přidá varování "nedělejte to!"??? To je snad jasný že to zkusim, ne?!

[vencour]

Stáhnout přes dwhelper a kouknout v mplayeru?

[kotyz]

ja uz to ani nestahuju, ja pockam az se to nacte a pak to zkopiruju z /tmp a prejmenuju na video.flv (o jak mi ten firefox (nebo snad sam flashplugin) vychazi vstric) ale nektery weby prehravajici flashovy video si ho do /tmp neukladaji (treba archiv novy) a tak se musi sahnout po nejakym stahoskriptu ...

[kralyk z abclinuxu]

ale nektery weby prehravajici flashovy video si ho do /tmp neukladaji (treba archiv novy) a tak se musi sahnout po nejakym stahoskriptu ...

To bude nejspíš tím, že tam to není flash video (flv), ale nějaký jiný stream. Třeba real-player nebo ten windows media (teď nevim jak se to menuje)... nevím teda jak na tv Hovna, ale ČT to tak má. Streamovací URL se z teho ale dá vytáhnout a vložit do VLC, který na tohle jako dělaný

[kotyz]

tv hovna ma flv, ale maji to udelany tak, aby to "neslo stahnout". musi se na to vzit rtmpdump

[vlastikroot]

Přes youtube-dl -g zjistit URL a pustit jako stream v mplayeru ?

[kotyz]

proc tak slozite, kdyz to de i jednodusejc ...

[vlastikroot]

Protože nemám flash. Mám napsanej scriptík, kterýmu jen hodim URL na youtube a on mi to pustí, pěkně přeškáluje na vhodnou velikost a nastaví správný výstup. Nebo si to mužu pustit v minitube, ale než honit na touchpadu nebo klitorisu myš, to radši dám v xtermu šipku nahoru a pastnu URL.

[=^..^= AmigaPower®]

Stáhnout přes dwhelper a kouknout v mplayeru?

Když se chci vychcat, vyáhnu ptáka a chčiju, nechci to dělat jako ženský, položit prkýnko, povolit pásek, sundat kalhoty, sundat spoďáry, sednout si, pak teprve chcát a ještě si k tomu utírat papírem ptáka...

[kotyz]

no a hlavne je tu nebezpeci z prodleni. mas v sobe par piv, uz ti to krouti nohy a ted nez polozis to prkynko a vsecky ty ostatni veci ...

[=^..^= AmigaPower®]

Dobrá poznámka.

[Luboš Doležel (Doli)]

Co teprve fsck.reiserfs... nedávno se mi samovolně rozsypal ReiserFS na desktopu, nechal jsem ho opravit přes fsck a ačkoliv ten tvrdí, že v souborovém systému nejsou žádné chyby, mount selže a hodí do dmesgu nějaké varování, že se něco rovná nule. Nádhera.

[kralyk z abclinuxu]

Jj, chování/ovládání reiserfsck je otřesné. Když chce člověk účinně opravit reiserfs filesystém, musí zvolit přesnou kombinaci --fix-fixable, --rebuil-sb případně --rebuild-tree ve správném pořadí, aby něco zachránil...
Nicméně alespoň je detereministický

[Kvakor]

--rebuil-sb je nutné jen při poškození superbloku, obvyklá taktika je prvně zkusit --fix-fixable, zkontrolovat a teprve při přetrvávání chyb použít --rebuild-tree. Ale pozor, při použití této volby nesmí být na disku v rámci partition zbytek žádného jiného ReiserFS souborového systému (např. v zálohách nebo testovacích souborových systémech připojovaných přes loopback), jinak se ho reiserfsck pokusí přifařit do nadřazeného souborového systému, čímž ho velmi pravděpodobně totálně zmrší ...

[kralyk z abclinuxu]

Pokud si vzpomínám, tak když reiserfsck spustíš bez argumentů, tak většinou řekne, jestli je potřeba rebuild superbloku nebo stromu, nebo jestli stačí fix-fixable. Na konci pak (někdy) vyhodí SIGINT, což u reiserfsck znamená "úspěšně jsem skončil"

Ale pozor, při použití této volby nesmí být na disku v rámci partition zbytek žádného jiného ReiserFS souborového systému (např. v zálohách nebo testovacích souborových systémech připojovaných přes loopback)

Přesně tak, to je specialitka reiserfs. Ve verzi 4, slibujou, už tohle prý nevadí.

[Bedňa]

--rebuild-tree