Konstantní testování integrity filesystemu

molly

Konstantní testování integrity filesystemu
« kdy: 26. 04. 2016, 22:23:23 »
Ahoj... Mel bych takovou malou otazecku na proces jbd2/sda2-8.
Jak jsem zjistil, je to proces zodpovedny za testovani integrity filesystemu. Po instalaci Manjaro LxQt 16.04 tento proces doleca dost zatezoval iowait asi na 2 hodiny (asi delal prvni test integrity ... to se mi stava na kazde distribuci a melo by to byt normalni). Potom se neozval asi 3 dny, ale nasledne jsem vycistil (rozumej prepsal) volne misto na disku pomoci BleachBit a nyni tento proces bezi konstantne na 1% iowait spolu s kworker procesy. Vypada to ze asi neni s tim prepisovanim volneho mista moc za dobre. Z toho odhaduji ze se dela nova kontrola integrity filesystemu. Problem je, ze timto tempem mu to bude trvat tak mesic :o.

Takze otazka je jestli se nemam obavat ze jsem si tim BleachBitem odpalil ext4 (tedy jestli se na to ted jeste da spolehnout) a jesli je to normalni stav nebo se nejak zacykloval? Prijde mi totiz divne, ze to dela "takhle pomalu".

Prikladam par screenu:

Glances s indikatorem iowait (zadny jiny program ted necte ani zezapisuje na disk):

Kód: [Vybrat]
http://postimg.org/image/f5ofuu8ld/
Iotop (zde muzete videt jbd2/sda2-8 a procesy kworker):

Kód: [Vybrat]
http://postimg.org/image/d0jelx0qp/
Vmstat:

Kód: [Vybrat]
http://postimg.org/image/m4iqp4075/
A zde maly prikaz na urceni pripadneho neprerusitelneho spiciho procesu zatezujiciho disk. Pokud vypisuje jen datum a cas tak neni problem:

Kód: [Vybrat]
http://postimg.org/image/r6inr7qbl/
« Poslední změna: 26. 04. 2016, 22:59:36 od Petr Krčmář »


JardaP .

  • *****
  • 11 064
    • Zobrazit profil
    • E-mail
Re:Konstantní testování integrity filesystemu
« Odpověď #1 kdy: 26. 04. 2016, 23:04:45 »
Nejak nechapu, jak by BleachBit mohl prepsanim souboru podelat Ext4, kdyz k tem suborum pristupuje pres FS a ne ve stylu nejake DOSove divociny hrabanim rovnou na disk. Jinak brani vam nejake objektivni priciny ve vynuceni fsck pri bootu a restartovani stroje?

molly

Re:Konstantní testování integrity filesystemu
« Odpověď #2 kdy: 26. 04. 2016, 23:36:19 »
Tak jsem zkontroloval filesystem a je OK. Pred chvili to prestalo hrabat asi po 22ti hodinach a ted je to v klidu. Jinak s tim DOSem mate pravdu ... BleachBit by mel byt bezpecny ... nicmene uz z principu se muze vloudit chybicka. Na beznem nezasifrovanem filesystemu je to asi v poradku... ale na Lubuntu se sifrovanim disku mi to asi nejak  >:( Pustim si tak video ve VLC a system spadl na cernou obrazovku s hlaskou "cryptsetup filesystem error". Tolik moje zkusenost s kombinaci BleachBit + crypto. Samozrejme to nemusi byt chyba BB.

Sten

Re:Konstantní testování integrity filesystemu
« Odpověď #3 kdy: 26. 04. 2016, 23:53:51 »
BleachBit "čistí" volné místo tak, že ho celé zaplní dočasnými soubory. Pokud to dělá na šifrovaném disku, tak se taky musí všechna ta data zašifrovat. Což, pokud jich je hodně (terabajty), může trvat opravdu i několik dní. (A pokud používá jen nuly, jak jsem pochopil z dokumentace, tak usnadňuje prolomení šifrování pomocí known plaintext útoku.)

molly

Re:Konstantní testování integrity filesystemu
« Odpověď #4 kdy: 27. 04. 2016, 00:23:20 »
Sten: Diky za tu informaci o usnadneni desifrovani. To ostatni je jasne ... dela to tak asi kazdy program na cisteni volneho mista ale co si pamatuji tak zasifrovany 1TB disk "temer" prazdny mi to prepisovalo jen asi 70 minut a ted pri stejne situaci, jen nesifrovany asi 60 minut. Jinak nevim, co je na tom pravdy, ale nekde jsem cetl, ze jdou obnovit i data ktera byla jednou prepsana a proto se doporucuje prepisovat nejmene metodou 3x. Dobry je shred na jednotlive soubory, ale pokud vim, neumi prepisovat volne misto a adresare.

shred -v -z -u -n3 file.xx


JardaP .

  • *****
  • 11 064
    • Zobrazit profil
    • E-mail
Re:Konstantní testování integrity filesystemu
« Odpověď #5 kdy: 27. 04. 2016, 00:50:23 »
... nekde jsem cetl, ze jdou obnovit i data ktera byla jednou prepsana a proto se doporucuje prepisovat nejmene metodou 3x.

Tak pokud se jedna o mechanicky disk a jde po vas NSA, tak principielne ano. Pokud po vas jde tchyne, tak muzete byt v klidu.

NSA by v zasade mohla delat asi dve veci. 1) Cist disk a zaznamenavat prubeh signalu tak, jak leze z cteci hlavy. Prubeh signalu bude vypadat jinak, jestli pri predchozim zaznamu byla na stejnem miste stejna hodnota nebo odlisna. Podle typu deformace signalu lze urcit, co tam bylo pred prepsanim. Tim by se ale dostali leda tak k predchozimu zaznamu, tezko dale. 2) Strcit plotny pod elektronovy mikroskop a cist je z fotografii. Hlavy disku ponekud plavou oproti idealni pozici, takze kazdy zaznam je o trochu vedle ve srovnani s predchozim a existuje tedy nadeje, ze nekde na okraji stopy zbyly kousky predchozich zaznamu, ktere by sly precist. To je narocne casove i financne, cert vi, jestli je to nejak automatizovane. Takze do neceho takoveho se hned tak nepusti, pokud nemaji duvodne podezreni, ze zrovna na vasem disku by mohli v zaplave mailu, porna, IM zprav, systemovych souboru, docasnych souboru.... najit ty plany na vojenske vyuziti Venuse a teleportaci USA na obeznou drahu okolo Proximy Centauri. Takze je na vas, abyste posoudil, kdo po vas jde. BTW, porad je levnejsi a rychlejsi, aby to z vas vymlatili francouzakem.

Co se tyka zmineneho plain text utoku, tak asi by pomohlo, kdyby BB soubory jen mazal a vy nasledne pustil cat /dev/urandom > /tmp/bordel;rm /tmp/bordel

BTW, system, kde si pustim VLC a spadne to s hlaskou cryptsetup filesystem error, bych radsi nepouzival. Zejmena ne na dulezita data. Nevim, jak ve vas, ale ve mne to nejak vyvolava neduveru.

Sten

Re:Konstantní testování integrity filesystemu
« Odpověď #6 kdy: 27. 04. 2016, 10:02:19 »
Sten: Diky za tu informaci o usnadneni desifrovani. To ostatni je jasne ... dela to tak asi kazdy program na cisteni volneho mista ale co si pamatuji tak zasifrovany 1TB disk "temer" prazdny mi to prepisovalo jen asi 70 minut a ted pri stejne situaci, jen nesifrovany asi 60 minut. Jinak nevim, co je na tom pravdy, ale nekde jsem cetl, ze jdou obnovit i data ktera byla jednou prepsana a proto se doporucuje prepisovat nejmene metodou 3x. Dobry je shred na jednotlive soubory, ale pokud vim, neumi prepisovat volne misto a adresare.

shred -v -z -u -n3 file.xx

Teoreticky by to asi možné bylo, ale u moderních disků s obrovskou hustotou zápisu je to velmi nepravděpodobné a nespolehlivé, a pokud po vás nepůjdou tajné služby (které stejně budou preferovat francouzák), tak zřejmě i legálně nepoužitelné.

molly

Re:Konstantní testování integrity filesystemu
« Odpověď #7 kdy: 27. 04. 2016, 10:55:15 »
Velmi zajimave. Jinak opravdu po me nikdo nejde ... spis me to jen zajima. K tomu Lubuntu co padlo... Dlouho jsem pouzival ruzne *buntu distribuce a podobne na nem nebo respektive Debianu zalozene a pokazde preventivne zasifrovane. Nikdy se mi tohle nestalo ... jen jednou v tom Lubuntu. Od te doby sifrovani uz nepouzivam. Ostatne ani nemam duvod. Nemam totiz stejne jako vetsina lidi co skryvat.

JardaP .

  • *****
  • 11 064
    • Zobrazit profil
    • E-mail
Re:Konstantní testování integrity filesystemu
« Odpověď #8 kdy: 27. 04. 2016, 11:35:59 »
Od te doby sifrovani uz nepouzivam. Ostatne ani nemam duvod. Nemam totiz stejne jako vetsina lidi co skryvat.

Porad jeste jsou veci soukrome, i kdyz nejsou nijak zvlast tajne a z hlediska tajnych sluzeb obzvlaste zajimave. A na ty lze pouzit EcryptFS, takze kdyz vam nekdo corne notebook, tak ma smulu, protoze infrastrukturu k rozsifrovani nema k dispozici.