linux-kernel - Re: EXT3 File System Corruption 2.6.34

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Mon, 07 Jun 2010 17:04:26 -0400
From:	Valdis.Kletnieks@...edu
To:	Jeffrey Merkey <jeffmerkey@...il.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: EXT3 File System Corruption 2.6.34

On Mon, 07 Jun 2010 14:45:38 MDT, Jeffrey Merkey said:
> Still seeing file system corruption after journal recovery in EXT3.

Are you getting bit by one of these mount options? (from 'man mount')
There were changes a few releases ago, might want to check what
your kernel build defaulted it to in your 2.6.34.

       data={journal|ordered|writeback}
              Specifies  the  journalling  mode  for  file  data.  Metadata is
              always journaled.  To use modes other than ordered on  the  root
              filesystem,  pass the mode to the kernel as boot parameter, e.g.
              rootflags=data=journal.

              journal
                     All data is committed into the  journal  prior  to  being
                     written into the main filesystem.

              ordered
                     This  is  the  default mode.  All data is forced directly
                     out to the main file system prior to its  metadata  being
                     committed to the journal.

              writeback
                     Data ordering is not preserved - data may be written into
                     the main filesystem after its metadata has been committed
                     to  the  journal.   This  is  rumoured to be the highest-
                     throughput option.   It  guarantees  internal  filesystem
                     integrity,  however  it  can  allow old data to appear in
                     files after a crash and journal recovery.

       barrier=0 / barrier=1
              This enables/disables barriers.   barrier=0  disables  it,  barâ
              rier=1 enables it.  Write barriers enforce proper on-disk orderâ
              ing of journal commits, making volatile disk write  caches  safe
              to  use,  at some performance penalty.  The ext3 filesystem does
              not enable write barriers by default.  Be sure to enable  barriâ
              ers  unless  your  disks  are battery-backed one way or another.
              Otherwise you risk filesystem corruption in case of power  failâ
              ure.


Content of type "application/pgp-signature" skipped