Messages in this thread |  | | Date | Mon, 02 Oct 2000 20:39:31 -0500 | From | Robert Redelmeier <> | Subject | Re: 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/
|  |