There Might Be Another EXT4 Corruption Bug

[gamerk2]

In Window$ we download patches for what we even haven't a clue for what they are.....

You can generally check the MSDN page for more info if you so desire.

and yes, one of the several reasons i dropped Window$ was data integrity because several times some games locked my rig and only way to switch off was to hard reset making data corruption....

Based on past experience, this typically indicates an unstable memory subsystem, usually due to the mobo's NB not being able to handle four DIMMS of high speed RAM. Some mobo chipsets (NVIDIA 680i/780i/790i, and most lower end ECS/Biostar mobos) were notorious for this once people started using all the RAM slots. Easy test for this would be to run Prime95 for a few hours and wait to see if that comes back with a rounding error (indicating memory corruption occured). Ran into this issue with my old crappy XFX 790i Ultra; had to overvolt the NB to 1.3V and underclock the RAM for stability. Ran fine on linux though (or rather: Could not reproduce. Didn't have an equivalent to Prime95 to test with)

[AdamW]

Hey guy who owns phoronix:

I red a blog post from a chinese kernel dev and he was saying you were just trolling for adhits and should stfu...


them seem like fighting words to me

ted ts'o isn't Chinese. He's American.

[Leslie508]

I'm happy for you if you format every 6 Months.

[NullNix]

I first encountered the EXT4 bug about six weeks ago. It's actually quite severe, crashing two of my systems due to file system corruption. At first I wasn't sure what it was and thought my hard disk might be going bad, but after it happened on two separate machines, I eventually figured out that EXT4 was the culprit by trial and error

If you could reproduce it, reporting it to the ext4 developers would have been nice. If you run away and just install something else, the bug will quite possibly never get fixed. It's quite unlikely to have been the bug I encountered (given what an unlikely concatenation of circumstances you need to reproduce that), and since the 'bug' just reported was not a bug at all it might be something else.

(I do wonder what Michael will yell about next. Perhaps he'll complain about the harmless dtime reset messages fsck gives you if you uncleanly unmount after doing an unlink()-and-close()? Hint, fsck saying it fixed something and proceeding happily after an unclean shutdown does *not* necessarily mean something is wrong. Start to worry only if you get a fsck exit with errorcode not ORed with 4 -- i.e., a 'human intervention required' fsck -- or if you get a clean filesystem followed by ext4 assertion failure messages or -EIOs at runtime. Actual crashes suggest substantial corruption, which is definitely problematic.)