lkml.org 
[lkml]   [2006]   [Jun]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [Ext2-devel] [RFC 0/13] extents and 48bit ext3
    Hi!

    > >Passes 8 hours of me trying to intentionally break it with weird,
    > >artifical disk corruption.
    > >
    > >I even have script somewhere.
    >
    > Ok, thanks for clarifying.

    You can get a copy, it would be interesting to know how JFS/XFS does.

    > >> Unless I'm misunderstanding something, JFS also has a
    > >> working fsck
    > >> (which has actually performed successful repair of
    > >> real-world
    > >> filesystem corruption for me, although I haven't used it
    > >> as much as
    > >> e2fsck or xfs_repair).
    > >
    > >...like, if it repaired 100 different, non-trivial corruptions, that
    > >would be argument.
    >
    > In the case of XFS, I've repaired maybe two dozen (or so) corruptions
    > that might be non-trivial (in most of the cases, the filesystem
    > wouldn't even mount before the repair).
    >
    > >fsck.ext2 survives my torture (in some versions). fsck.vfat never
    > >worked for me (likes to segfault), fsck.reiser never worked for me.
    >
    > BTW, I actually have a test filesystem here (an e2image from an actual
    > filesystem I encountered once) that used to cause e2fsck 1.36/1.37 to
    > segfault. Strangely, more ancient versions (like what ships in Red Hat
    > 7.2) were able to repair it without segfaulting. In a few days, once
    > other stuff calms down for me, I need to revisit that and see if the
    > bug still exists with 1.39.

    It varies a bit bitween versions, but at least e2fsck has regression
    test suite... I had nasty e2 corruption in past (suspend wrote 0 onto
    strategic place in bitmaps) where it put filesystem in self-destruct
    mode. e2fsck reported fixing the corruption, but did not really fix
    it... e2fsck was fixed in the meantime.

    (I also have way to corrupt ext2 in a way that basically can't be
    repaired automatically. Deallocating free block bitmap and putting
    data in freed space is an evil way to corrupt filesystem).
    Pavel
    --
    (english) http://www.livejournal.com/~pavelmachek
    (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2006-06-15 11:20    [W:4.677 / U:0.016 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site