linux-kernel - Re: Spurious Filesystem corruption with ext3 + large (<400GB) hw RAID partition + SMP

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:	Sat, 31 Jan 2009 11:46:51 -0200
From:	Henrique de Moraes Holschuh <hmh@....eng.br>
To:	Manfred Wassmann <tux.wassmann@...glemail.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: Spurious Filesystem corruption with ext3 + large (<400GB) hw
	RAID partition + SMP

On Sat, 31 Jan 2009, Manfred Wassmann wrote:
> I'm experiencing spurious filesystem corruption problems with ext3 on
> a partition larger than 400 GB on a hardware SATA RAID.

Please describe the SATA RAID hardware in a bit more detail.  Which
SATA controller does it use?

Also, have you made sure it is not caused by bad memory?

> The problems first occured on an Intel dual core system with a custom
> installation DVD which uses a 32 bit 2.6.26 kernel with SMP enabled
> and a 4GB memory limit. The problems occured only randomly but it was
> possible to reproduce them reliably with a standard Ubunu installation
> disk using a 2.6.27-7 kernel (apparently also 32bit SMP kernel w 4GB
> limit).
> When installing Ubuntu a message appears in the kernel log stating:
> "EXT3-fs error (device sda6): ext3_vlid_block_bitmap: Invalid block
> bitmap - block_group = 3076, block = <some large number>"
> This message is the first indication of any problem, the filesystem is
> then remounted readonly and the installation stops understandably.
> 
> The problem does only occur with an ext3 filesystem, installation
> using an xfs filesystem completes without error.
> 
> Furthermore with the installation from my custom installation DVD
> succeeded, which installs a prebuild Debian etch system featuring a 64
> bit monolithic 2.6.26 kernel, i was able to stress the system to its
> limits using the stress and dbench programs without any sign of
> filesystem corruption.
> 
> As XFS does substantially outperform ext3 under the given
> circumstances I'm going to use that but if someone wants to
> investigate the problem and needs further details I'll do my very best
> ;-)

Be careful.  XFS might not trigger the problem as readly, but it could
still be there and you can suffer data loss.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/