[clue-tech] intentionally induce ext3 filesystem errors for testing recovery procedure?

[Keith Hellman]

On Tue, Apr 20, 2010 at 11:49:09PM -0600, Jim Ockers wrote:
> I think I've got most of the logic figured out for how this needs to 
> work.  But I need to induce moderate filesystem corruption so I can test 
> all of the cases.  A google search made me think nobody has ever wanted 
> to intentionally corrupt a filesystem.  Do any of you have any 
> suggestions for what I could do?  Obviously I can dd garbage over the 
> superblocks, but I think that will just make fsck exit 4.

You may have already done this, but I would give a pretty thorough read
to debugfs(8).  The last time I read it (6+ months?), I recalled lots of 
  "don't do this unless you know what you're doing"
admonitions.  Sounds like it could induce some sort of corruption.

Do you know what the failure modes will be?  Presumably there will be
just a few (hopefully) ways you expect the system or hardware to fail
--- these might create just a sliver of all the corruption issues that
fsck can fix --- do you need exhaustive testing or just the usual
suspects.  Probably Ted or another Linux FS developer can best answer
this.

Instead of repair, would it be reasonable to:
 1. make a ramdisk
 2. compress the log block device onto the ramdisk
 3. (re)mkfs the log filesystem
 4. ship the compressed block device off for remote forensics
Is this feasible for the machine?  Does it have a active or transient
network connection?  The reason for this approach would be that if 1-4
can't be done, it sounds like game-over for the machine.  Whereas I
could envision cases where fsck might *not* be able to repair the log
system --- what are the outcomes of this?  What is the risk?

IIRC, your a PE so you've got a handle on the FMEA.  Just another
thought for a solution --- probably one you've already considered.

-- 
Keith Hellman                             #include <disclaimer.h>
khellman at mcprogramming.com                from disclaimer import standard
khellman at mines.edu
                                   -*-                                    
                    public key @ pgp.mit.edu 9FCF40FD 
    Y!M: mcprogramming                           AIM/ICQ: 485403897       
   gtalk (xmpp jabber): mrtuple at jabber.org, jabber at mcprogramming.com                      
                                   -*-                                    

"The First Python function ever written (takes place in the Garden of Eden)"

Guido sayeth "I will write def foo():"
"Hmm, I could use an import, or two",
Satan said, in a whirl, "Why not write it in Perl?",
and the second function ever written -  def foo_you(): 

-- Python Limmerick Contest submission by cappy2112
   http://groups-beta.google.com/group/comp.lang.python/browse_thread/thread/d7a780beaff2e88a/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
Url : http://cluedenver.org/pipermail/clue-tech/attachments/20100421/54001e7e/attachment.bin