Chyba poškozující ext4 byla opravena (diskuse)

[loki]

Nevite pls nekdo, jakych se to tykalo jader?

[xkomczax]

V jádře 3.6.2 a novějších byla nalezena chyba v ext4, která způsobuje poškození nebo ztrátu dat. Chyba byla backportována i do řad 3.4 a 3.5.

[michich]

To je zprávička ještě z doby, kdy vývojáři pracovali s chybnou teorií. Chyba je v jádrech již od 3.4, ale týká se málokoho, protože k reprodukování je potřeba použít zvláštní mount option.

[loki]

Dekuji vsem za vysvetleni.

[JoHnY2]

Uf to jsem si oddych.

[AraxoN]

Tak to sme dvaja!

[Nikola Pajkovský]

ja si rikal, jak jsem v klidu, ze mam xfs a dneska jsem zazil corruption na xfs

[trubicoid2]

mne taky zacal blbnout xfs na /, nekdy se nenamountuje a jadro panikuje, co to je? to teda drive nedelalo :(

[Nikola Pajkovský]

jaky mas kernel? sprasim nejaky mail maintainrum.

[trubicoid]

dela mi to s 3.6.2 a 3.6.4, u dalsich verzi si nejsem jisty

[trubicoid]

tak dneska znova, kernel 3.6.6 nenamountoval a kernel 3.2.19 (z systemrescuecd) to normalne namontoval

mas nejakej napad?

ja priste asi udelam image disku do souboru a budu to vic testovat

[Nikola Pajkovský]

ja jsem na to jeste nemel cas. moc se mi to nechce testovat na root oddilu, takze si budu muset sehnat externi disk, udelam mirror a zkusim to vypustit.

~/upstream/vanilla $ git log --oneline v3.6.. | wc -l
12178

bisekce chvilku potrva, nez najdu commit, ktery to dela

[trubicoid]

tak Dave uz to nasel, chyba byla uz prej v 3.0-rc1, ale projevuje se to az ted :(

http://oss.sgi.com/archives/xfs/2012-10/msg00641.html

Dave & XFS rules :)

[trubicoid]

a uz je to v 3.7-rc3

http://oss.sgi.com/archives/xfs/2012-11/msg00019.html

[Nikola Pajkovský]

me se to stalo prave na 3.7-rc3

[Nikola Pajkovský]

tak a ted mi to sezralo znacnout cast (temer kazde git repo nefunguje) /home

[trubicoid]

kurnik

a neni to tim, ze to bylo rozbity predtim od 3.0? teda ja vzdycky mezi vytuhama udelal xfs_repair a tim se to asi opravilo

[trubicoid]

tak koukam, v 3.7-rc4 to jeste neni opraveny, asi ten jednoznakovej patch jeste nezaradili

musis opatchovat rucne

[Nikola Pajkovský]

hecnu to, stejne nevim co je vse v knedlu

[Nikola Pajkovský]

tazke uz je to v xfs strome 009507b052fa391618eccf9e8c9f484407fd9018 a taky v linux-next, vanilla pozatim nic. pullnul jsem xfs z xfs stromu (stejny jako v linux-next) a jdu to zkusit. cross fingers

[trubicoid]

ja to vopatchoval rucne vcera, ale od te doby to jeste nespadlo, tak potom uvidime

[trubicoid]

je to v 3.7-rc5, ted jsem to kontroloval

[Tomáš]

No třeba to s tím nesouvisí, ale od doby, co jsem o minulém víkendu upgradoval z fedora 16 na fedora 17 a kernel 3.6, tak jsem už pětkrát musel absolvovat ruční fsck, protože systém nenaběhl. Předtím jsem to léta nezažil

[Bedňa]

Tak ako ext hater môžem povedať, že sa konečne po rokoch dostalo do použiteľnej podoby. ext2 nevedela nič ale išla dosť rýchlo, ext3 stojí úplne za kulové a každému komu som doporučil prechod na ReiserFS si pochvaloval. Ext4 sa konečne po dlhom čase dostala na úroveň ReiserFS to že sa Reiser už roky nevyvíja zabudnime. Ext4 používam pár mesiacov a spokojnoť, len kde by bol Reiser dnes, že.

[D.A.Tiger]

prosím, nebyl by článek (nejlépe v czech) který ext3 a ReiserFS srovnává? Dík.

[Bedňa]

Tak posledné testy na Phoronixe ma presvedčili, je to pár mesiacov dozadu link fakt nemám. Hlavne zmizli tie random iotop zaťaženia aj keď komp nič nerobil ext dokázalo zožrať všetky systémové prostriedky, to sa tiahlo celé roky od začiatku ext3 až po ext4. Ako ukážku si stačí nainštalovať ext3 dať ls /usr/bin a v porovnaní s Reiserom to bude tak 1 ku piatim čo sa týka času a vyťaženia procáku nehovoriac. Proste nešlo o nič nehovoriace percentá ale niekoľko násobky prístupového času a tie random zaťaženia boli ako bonus.

[Michal Fecko]

JFS je najlepší. Můžeme o tom diskutovat, můžeme o tom vést spory, můžeme s tím nesouhlasit, ale to je tak všechno, co se proti tomu dá dělat.

[Bedňa]

Používaš ho aj na desktope?

[Martin Mareš]

Jinými slovy, naprosto exaktní experiment

[D.A.Tiger]

Hmmm, to mi moc asi nepomůže. V jednom okně konsole jsem spustil jsem htop, v druhém ls /usr/bin a se zatížením zdrojů to nijak viditelně nehlo Obávám se, že tyhle výsledky bych neměl moc s čím srovnávat

PS. Mám ext3

[Bedňa]

Tak by mohlo stačiť použiť time ls /usr/bin

[Jendа]

~ # time ls /usr/bin > /dev/null 

real	0m0.796s
user	0m0.028s
sys	0m0.028s
~ # time ls /usr/bin > /dev/null 

real	0m0.041s
user	0m0.028s
sys	0m0.012s
~ # ls /usr/bin |wc -l
3982

Intel Atom N270 "486 Enhanced Edition", 5400 RPM disk, ext4

[Jendа]

Jo takhle, u ext4 se to nemá projevovat? No u ext3 jsem si ničeho takového taky nevšiml.

[Bedňa]

Ako som písal ext4 je už ready, ten prvý čas bolo prvé ls?

time ls /usr/bin > /dev/null 

real	0m0.042s
user	0m0.004s
sys	0m0.012s

mario@s29:~$ time ls /usr/bin > /dev/null 

real	0m0.020s
user	0m0.004s
sys	0m0.012s

ls /usr/bin |wc -l
1818

Ostatné pod 0.020ms, AMD Athlon(tm) II X2 250 Processor, fdparam mi rýchlosť disku nedal. ext4.

[D.A.Tiger]

hmmm ... mě se to pořád nezdá tak špatné....

Čt 08/11/2012 13:51 (~)> time ls /usr/bin > /dev/null

real    0m0.394s
user    0m0.008s
sys     0m0.040s
Čt 08/11/2012 13:51 (~)> time ls /usr/bin > /dev/null

real    0m0.022s
user    0m0.016s
sys     0m0.008s
Čt 08/11/2012 13:52 (~)> time ls /usr/bin > /dev/null

real    0m0.023s
user    0m0.012s
sys     0m0.012s
Čt 08/11/2012 13:52 (~)> time ls /usr/bin > /dev/null

real    0m0.022s
user    0m0.016s
sys     0m0.008s
Čt 08/11/2012 13:52 (~)> ls /usr/bin | wc -l
3521
Čt 08/11/2012 13:55 (~)>  grep model /proc/cpuinfo 
model           : 23
model name      : Pentium(R) Dual-Core  CPU      E5700  @ 3.00GHz

HDD: WDC WD5000AAKS-6 FS: EXT3

[trubicoid2]

Opraveno v 3.6.6