Responding to ext4 journal corruption [LWN.net]

Responding to ext4 journal corruption

Posted May 30, 2008 13:43 UTC (Fri) by masoncl (subscriber, #47138)
In reply to: Responding to ext4 journal corruption by jzbiciak
Parent article: Responding to ext4 journal corruption

Reiserfsv3 and jbd both use write ahead logging schemes, and so they solve very similar
problems.  Reiserfs keeps tracks in ram of which blocks are pinned and not available for
allocations, while jbd uses these revoke records.

Keeping track in ram has performance implications, but it is certainly possible.

(Log in to post comments)

Responding to ext4 journal corruption

Posted Jun 7, 2008 17:20 UTC (Sat) by Duncan (guest, #6647) [Link]

That's probably one of the big reasons I've found reiserfs (3) so stable 
here, at least after ordered-by-default hit the tree.  I ran a system for 
some time with an annoying memory bus error issue (generic memory rated a 
speed notch higher than it should have been, a BIOS update eventually let 
me limit memory speed by a notch, after which it was absolutely stable) 
that would crash the system with MCE errors relatively frequently.  100% 
reiserfs, no UPS, no problems after ordered-by-default, tho I certainly 
had some previous to that.

I'm running the same system but with a memory and CPU upgrade now, and 
with reiserfs on mdp/kernel RAID-6, system directly on one RAID-6 
partition (with a second for a backup system image), everything else on 
LVM2 on another one.  Despite the lack of barriers on the stack as 
explained in last week's barrier article, and despite continuing to run 
without a UPS and having occasional power outages that often trigger a 
RAID-6 rebuild, I've been VERY happy with system integrity.

Duncan