Newsgroup: it.comp.os.linux.iniziare
Titolo: Bug kernel 2.4.20!!!!! ext3 data corruption...

Riporto il post relatvo ad un bug
scoperto nel kernel 2.4.20,
l'indirizzo del thread è
http://www.redhat.com/mailing-lists/ext3-users/msg08798.html
In 2.4.20-pre5 an optimisation was made to the ext3 fsync function
which can very easily cause file data corruption at unmount time.  This
was first reported by Nick Piggin on November 29th (one day after 2.4.20
was
released, and three months after the bug was merged.  Unfortunate timing)
This only affects filesystems which were mounted with the `data=journal'
option.  Or files which are operating under `chattr -j'.  So most people
are unaffected.  The problem is not present in 2.5 kernels.
The symptoms are that any file data which was written within the thirty
seconds prior to the unmount may not make it to disk.   A workaround is
to run `sync' before unmounting.
The optimisation was intended to avoid writing out and waiting on the
inode's buffers when the subsequent commit would do that anyway. This
optimisation was applied to both data=journal and data=ordered modes.
But it is only valid for data=ordered mode.
In data=journal mode the data is left dirty in memory and the unmount
will silently discard it.
The fix is to only apply the optimisation to inodes which are operating
under data=ordered.
--- linux-akpm/fs/ext3/fsync.c~ext3-fsync-fix   Sat Nov 30 23:37:33 2002
+++ linux-akpm-akpm/fs/ext3/fsync.c     Sat Nov 30 23:39:30 2002
@@ -63,10 +63,12 @@ int ext3_sync_file(struct file * file, s
         */
        ret = fsync_inode_buffers(inode);
 
-       /* In writeback mode, we need to force out data buffers too.  In
-        * the other modes, ext3_force_commit takes care of forcing out
-        * just the right data blocks. */
-       if (test_opt(inode->i_sb, DATA_FLAGS) ==
EXT3_MOUNT_WRITEBACK_DATA)
+       /*
+        * If the inode is under ordered-data writeback it is not
necessary to
+        * sync its data buffers here - commit will do that, with
potentially
+        * better IO merging
+        */
+       if (!ext3_should_order_data(inode))
                ret |= fsync_inode_data_buffers(inode);
 
        ext3_force_commit(inode->i_sb);
--
Klunk
"Tranquillo capo, prenderemo
quel dannato aauuughlll piccione!"

 option.  Or files which are operating under `chattr -j'.
Non c'e' da preoccuparsi, di default ext3 viene montato con data=ordered e non
data=journal
Per cui credo che si possa dormire sogni tranquilli, specialmente per il fatto
che probabilmente il bug era già presente fin dalla 2.4.19
-- 
| /
| \Byte - Andrea Briganti - kbytesys(at)
tiscali.it
http://www.kbytesystem.fasturl.it
 - ICQ: 40872731
*** Chi non ha rispetto non merita considerazione

che probabilmente il bug era già presente fin dalla 2.4.19
vero.... ma che differenza c'è tra le due modalità?
l'ext3 non è journaled di suo? oppure la modalità
data=journal è ancora più sicura (in teoria) della ordered?


 data=journal è ancora più sicura (in teoria) della ordered?
se non sbaglio il tipo di giornale è diverso come organizzazione in ambito di
performance. Il problema avviene perchè non è rilevata bene l'azione di unmount
rispetto a una normale scrittura su disco, con relativo no sync dei dati.
Ma ciò accade solo con quello stile di journal, almeno leggendo bene sulla
mailinglist.
