jump to navigation

Risolta con Linux 2.6.30 la perdita di dati con EXT4

In Espresso il 16/03 @ 12:45 trackback

Shared by felipe

C’è stato un bel po’ di rumore sul malfunzionamento del nuovo filesystem EXT4, che causa perdita di dati. Sembra che con la versione 2.6.30 del kernel avremo una soluzione.

Alexander Larsson ha scritto un ottimo articolo tecnico a riguardo (lettura consigliata!), in cui descrive alcune tecniche di aggiornamento dei file utilizzate in vati sistemi. Alla fine fa un piccolo sunto della situazione attuale di alcuni filesystem per Linux.

There has been a lot of discussion about the ext4 data loss issue…

This is the current status of the rename method on the commonly used Linux filesystems to my best knowledge:
(In this context “safe” means we get either the old or the new version of the file after a crash.)

ext2: No robustness guarantees on system crash at all.

ext3: In the default data=ordered mode it is safe, because data is written before metadata. If you crash before the data is written (5 seconds by default) you get the old data. With data=writeback mode it is unsafe.

ext4: Currently unsafe, with a quite long window where you risk data loss. With the patches queued for 2.6.30 it is safe.

btrfs: Currently unsafe, the maintainer claims that patches are queued for 2.6.30 to make it safe

XFS: Currently unsafe (as far as i can tell), however the truncate and overwrite method is safe.

— Pagine forse correlate:


Commenti »

1. Fedz - 16/03 @ 13:43

Ottimo, avevo giusto infilato un commento nella buchetta del messagebox perché m’ero preoccupato per Jaunty. Sempre puntuale Felipe ;)

2. Neff - 16/03 @ 15:05

ma in Jaunty quale versione del kernel verrà inclusa?

3. LtWorf - 16/03 @ 16:06

Sicuramente non la 2.6.30…

4. jk - 16/03 @ 17:28

2.6.28

5. lolloso - 17/03 @ 7:43

il fatto che ci sia un .29 in jaunty cosa vi cambia ?
Il problema segnalato di riferisce a ext4 e non al “vecchio” ext3,
in’oltre, non siete obbligati a installarlo su una partizione ext4, quindi non si pone il problema.

6. Patch - 17/03 @ 10:59

Da quanto ho capito con la patch etx4 si comportebbe come ext3,
a scapito di un decadimento di prestazioni.
Benchmark da rifare.

7. LtWorf - 17/03 @ 12:58

E non è finita. Il problema è sorto per colpa di kde4 che crashando elimina le impostazioni. Tuttavia la patch non risolve niente, perché il problema si verifica anche su ext3 e reiserfs (anche se la frequenza con cui accade su questi filesystem è minore).

8. Dass - 17/03 @ 19:42

io uso ext4 da un pò e non ho mai avuto problemi, anzi va sensibilmente meglio di ext3
quando a crash di kde… mah a me non capita mai, non saprei.

9. linuser - 17/03 @ 22:43

In particolare un commento in calce all’articolo originale mi sembra il più sensato : http://blogs.gnome.org/alexl/2009/03/16/ext4-vs-fsync-my-take/comment-page-1/#comment-534 , anche se in altri la cosa viene bollata come non-fattibile/preferibile

I prefer a solution without direct flush or fsync; It has been reiterated all over, but what we really REALLY want is atomicity.. either the new file or the old file, even after the crash. What the ext4 devs tell us and others toss us the POSIX book in the head and say.. we have to flush to disk to get that.. that’s just not an elegant solution. I want my laptop to defer writes and use all of linux awesomeness, working in RAM for a while etc etc.

Save my battery!
Don’t truncate my files!
Make it atomic and recover to either state after crash — pre or post write.

So the pragmatic solutions are good, but not perfect. Perfect would be preserving ordering to make sure renames can’t erase the whole file.

10. felipe - 18/03 @ 11:01

@tutti:
Qualunque siano le ipotesi e le scelte dei distributori… Credo che per adesso possiamo tranquillamente continuare ad accontentarci di EXT3 ;)

11. Dass - 18/03 @ 20:25

mah io continuo con ext4
stiamo a vedere