Andreas Dilger wrote in part:
>
> Albert Cahalan write:
> > The nice way to develop this code is with a block device that
> > discards all writes after a timer goes off.
This is nice, but a bit destructive for my likes. Hard and long to
do multiple tests. Also, it misses one severe case: an inode
overwritten with trash at the momemt of powerfail.
> I made a patch to the loopback device which allows you to discard I/Os
> going to disk. You can either activate it via an ioctl from user space,
> or via a function call in the kernel.
Neat.
> You can also make reads fail, but this was not very useful for me, because
> it caused the ASSERTs in ext3 to oops. Also the read "failures" are not
> the same as the real thing, so it may not be a valid test. They only
> return a zero'd page, rather than really causing a non-up-to-date page.
I think read failures are the way to go. Non-destructive, and you can
simulate the `fsck` by reading through an artificial /dev/dirty. The
trick, of course, would be in writing /dev/dirty. You could do it by
statistically examining the write buffer cache. Or you could do it
by recording (journalling-ack!) all overwritten data prior to time T,
(umount) and having /dev/dirty return the old inodes during fsck. For
added fun, /dev/dirty could chose to 'read error' any selected inode
like the superblock, or perhaps worse, /lib metadata.
With this technique, using the real `fsck` in no-mod, output only mode,
you could run quite a number of simulated crashes quickly. Maybe even
Monte Carlo with enough RAM (1+GB) to load a reasonable sized fs in RAM.
-- Robert
-- Robert
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
