On 8/10/07, Theodore Tso <tytso@xxxxxxx> wrote: > On Fri, Aug 10, 2007 at 03:41:32PM +0300, Kosta Kliakhandler wrote: > > > > I have a severe problem - I was a fool and made / (root) ext4 (at > > least not /home, thank god) and somehow some corruption occured. > > While running fsck, it keeps segfaulting, complaining about fast > > memory corruption (segfaults always at the same inode, always when I > > tell it to fix it). I *think* the issue was addressed in > > e2fsprogs-1.40.2 (from what I understood in the changelog) > > What, you mean this one? > > A recent change to e2fsck_add_dir_info() to use tdb files to check > filesystems with a very large number of filesystems had a typo which > caused us to resize the wrong data structure. This would cause a > array overrun leading to malloc pointer corruptions and segfaults. > Since we normally can very accurately predict how big the the dirinfo > array needs to be, this bug only got triggered on very badly corrupted > filesystems. > > If so, it couldn't be, since the tdb support was only added in > e2fsprogs 1.40, and you're using the 1.39 patchset, right? So it has > to be some other problem, and probably a bug which gets triggered when > it runs across a corrupted extent entry. > > How big is your root filesystem image? Unfortunately e2image hasn't > been updated support extents yet (there's a reason I keep telling > people ext4 isn't quite ready for prime time yet...), so we can't use > a compressed e2image file. > > - Ted > Yes, this was what I thought about... Well, maybe it wasn't that bug, but what happened to me certainly seemed similar - especially since after applying the extents patch which andreas supplied, it worked well. When I ran the new one, it reported that the problematic inode is in position -1 and not 0, so I guess this is what caused the problems in 1.39. Anyway, thanks for the help. Regards, Kosta. -- Kosta.tk - To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
