Linux-kernel mailing list archive 2000-40,: Re: Soft-Updates for Linux ?

# Re: Soft-Updates for Linux ?

Robert Redelmeier (redelm@ev1.net)
Mon, 02 Oct 2000 20:39:31 -0500

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Daniel Phillips: "Re: Tux2 - evil patents sighted"
- Previous message: tytso@mit.edu: "Re: What is up with Redhat 7.0?"
- Maybe in reply to: Robert Redelmeier: "Soft-Updates for Linux ?"

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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

- Next message: Daniel Phillips: "Re: Tux2 - evil patents sighted"
- Previous message: tytso@mit.edu: "Re: What is up with Redhat 7.0?"
- Maybe in reply to: Robert Redelmeier: "Soft-Updates for Linux ?"