Friss információk a "komoly" ext4 buggal kapcsolatban

Fájlrendszer, NAS, storage

Theodore Ts'o friss infókat tett közzé azzal az ext4 fájlrendszer buggal kapcsolatban, amely egyes weboldalaknak köszönhetően komoly aggodalmakat, pánikot keltett egyesekben. Ted nem tudta reprodukálni a bugreportot beküldő személy által jelentett hibát alapértelmezett mount opciók használata mellett. A teóriája az, hogy a hibát bejelentő személy - aki olyan nem szokványos mount opciókat használ, amelyek le is vannak alapértelmezetten tiltva, mert a fejlesztők tudják róluk, hogy problémásak - tudja csak megbízhatóan reprodukálni a hibajelenséget.

A lényeget összefoglalva Ted így írt:

In general, you should use ext4 with the default mount options unless you really are an expert and know what you are doing. We've had plans to create warninigs for the more experimental bits of ext4,

Általánosságban, az ext4-et az alapértelmezett mount opciókkal kell(ene) használnod, hacsak nem vagy tényleg szakértő és tudod, hogy mit csinálsz. A fejlesztők azt tervezik, hogy figyelmeztető üzeneteket hoznak létre az ext4 még kezdetlegesebb, kísérletibb, fejlesztés alatt álló részeihez.

A részletek itt olvashatók.

( STP | 2012. 10. 28., v – 11:24 )

"A fejlesztők azt tervezik, hogy figyelmeztető üzeneteket hoznak létre az ext4 még kezdetlegesebb, kísérletibb, fejlesztés alatt álló részeihez."
És elindultak a btrfs útján...

Kapcsolódik:

The problem is this code isn't done yet, and journal_checksum is
really not ready for prime time. When it is ready, my plan is to wire
it up so it is enabled by default; at the moment, it was intended for
developer experimentation only. As I said, it's my fault for not
clearly labelling it "Not for you!", or putting it under an #ifdef to
prevent unwary civilians from coming across the feature and saying,
"oooh, shiny!" and turning it on. :-(

- Ted

--
trey @ gépház

( freeoli v | 2012. 10. 28., v – 12:10 )

Nekem bűzlik hogy ez egybeesik az új windows verzió bemutatásával :S szófelhő: komoly adatvesztés hiba linux kernelben ismeretlen nem reprodukálható ismeretlen körülmények

Hát az nekem is gyanús, hogy egyvalakinek gondja támadt vele, hatalmas hír lett belőle, aztán kiderül, hogy csak az illető volt fasz. Ha minden egyes adatvesztés ilyen hírt tudna generálni, akkor azt mondanám, hogy oké, de így nekem is gyanús, hogy direkt csinálták lejáratási céllal. Amikor nekem elszállt az egész gépem, mert elment alatta az áram, akkor nem álltam neki körbekürtölni, hogy ne használt az ext3-at, mert elvesznek az adataid (apró betűs rész: naplózás nélkül és írás közben kihúzva a konnektorból).

( uid_16313 | 2012. 10. 28., v – 12:20 )

"Theo teóriája"

--
robyboy

"Gondolkozni nehéz, ezért legtöbben ítélnek." - Márai Sándor

( uid_19334 | 2012. 10. 28., v – 14:43 )

,,tudja csak megbízhatóan reprodukálni a hibajelenséget."

:D

( trey | 2012. 10. 28., v – 15:30 )

Nix (a hiba eredeti bejelentője) írta:

My latest tests indicate that unless you use journal_checksum or journal_async_commit (which implies journal_checksum), neither of which are the default, you appear to be safe. Unless you use nobarrier *too* (which you really shouldn't unless you have suitable hardware, which means battery-backed disk controllers: a PSU isn't good enough), you will see a journal abort and a readonly remount of the fs at next mount. You need both journal_async_commit *and* nobarrier to get no journal abort and silent fs corruption.

--
trey @ gépház

( dj | 2012. 10. 29., h – 10:07 )

Ez az egész olyan, mint egy biliben a vihar. És mennyien tudnak rugózni rajta, hihetetlen :)