EXT4 Data Corruption Bug Hits Stable Linux Kernels

As a warning for those who are normally quick to upgrade to the latest stable vanilla kernel releases, a serious EXT4 data corruption bug worked its way into the stable Linux 3.4, 3.5, and 3.6 kernel series.

Being discussed recently on the Linux kernel mailing list was an "apparent serious progressive ext4 data corruption bug in 3.6.3." Theodore Ts'o was able to successfully bisect the kernel and found the serious bug, which first appeared within the Linux 3.6.2 kernel and was since back-ported to older stable kernels.

http://www.phoronix.com/scan.php?page=news_item&px=MTIxNDQ

De mindjárt jön valaki, aki ugyan világ életében Windows-t használt, de hallotta, hogy 1999-ban volt egy komoly bug a ReiserFS-ben, aminek következtében a haverjának haverja összes pornóját elveszítette és emiatt a ReiserFS SZAR!!!

Szerveren egyelőre még nem mertem ext4-et használni, ext3 a preferált.

--
trey @ gépház

En most kukaztam egy olyan virtualis gep disket, ahol minden xfs-en volt. Egy crash utan szepen bekoltozott minden file a lost+found mappaba, random neveken. Kesz szerencse, hogy adat nem tartozkodott a gepen.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Nálam csak a home van XFS-en, de az meg raid1 -ben, heti 1 teljes mentés, naponta különbözeti mentéssel, szóval nem mondom hogy örülnék egy összeomlásnak, de tragédia nem lenne belőle, vissza tudom állítani. A többi partíció EXT3 van. Ahol meg Reiser van home-nak, ott szintén raid1, rendszeres mentés, a többi ott is ext3.

Egyszer már nekem is volt xfs gondom, de ennek ellenére bízom benne. Nekem bejövős. ;)

Rózsár Gábor (muszashi)

Most szólok, azok a random nevek szinte bztosan #inode-szám alakúak voltak. Most az, hogy az emberek jelentős része nem tudja fejből a fontos fájljainak i-node-számát, hát az már egyedi pech :-) Pedig mennyivel rövidebbek, mint egy átlagos IPv4-es cím (nyilván az IPv6-ról már nem is beszélve).

Na nekem ext3 játszotta totál ugyan ezt :D XFS-nél még nem sikerült reprodukálnom, pedig kapott már 1-2 áramszünetet..
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Csak elég áramszünet kell és minden mai átlagos fájlrendszert utolér a végzete, hacsak nincs bekapcsolva a barriers, így születnek a rémtörténetek. :)

Virtuális gépen a bekapcsolt writeback cache szinte garantált fs korrupció áramszünetnél / kernel pániknál, hiszen a host writeback cache-ként használt ramja többszöröse a HDD-knek és jóval ritkább a flush is, így a kockázat is sokszoros. A probléma ugyanarról a tőről fakad csupasz- és virtuális gépnél is: reordered write.

barriers or die :)

( tgerczei | 2012. 10. 24., sze – 16:57 )

Nekem volt egy KH-s tápcsatlakozójú külső tokban egy lemezem ReiserFS-sel, amin tokcsere után évekkel derült csak ki, hogy a csattanós csuklások során mókás baleset érte néhány MP3 file-omat: eltérő albumok számai "mosódtak egybe" néhol :] Amúgy Linuxon magam is mindmáig megmaradtam a ReiserFS-nél. Problémamentes minden tekintetben.

/etc/lib/lu/plugins/lupi_bebasic