Stephen Tweedie did something like this already (for 2.4.19-pre10),called "testdrive". It uses loopback over a block device.He says that it will need modifications to use bio in 2.5.

See here:http://marc.theaimsgroup.com/?l=linux-kernel&m=102457399020069&w=2

-- ~Randy

| Hmmm... Not being familiar with the SCSI layer but sticking my nose in anyway| on general block device/mount point hotplug issues:|| How hard would it be to write a simple debugging function to lobotomize a| block device? (So that all further I/O to that sucker immediately returns an| error.) Not just simulating an a hot extraction (or catastrophic failure) of| a block device, but also something you could use to see how gracefully| filesystems react.|| The reason I ask is there was a discussion a while back about the new lazy| unmount (umount -l /blah/foo) not always being quite enough, and that| sometimes what what you want is basically "umount -9 /blah/foo" (ala kill| -9). Close all files, reparent all process home directories and chroot mount| points to a dummy inode, flush all I/O, drive a stake through the| superblock's heart, and scatter the ashes at sea. Somebody posted a patch to| actually do this. (Against 2.4, i think.) I could probably dig it up if you| were curious. Let's see...|| http://marc.theaimsgroup.com/?l=linux-kernel&m=103443466225915&q=raw|| The eject command should certainly have an "umount with shotgun" option, so| zombie processes can't pin your CD in the drive. (Your average end-user is| NOT going to be able to grovel through /proc to figure out which processes| have an open filehandle or home directory under the cdrom mount point so it| can kill them and get the disk out. They're going to power cycle the machine| and eject it while the bios is in charge. I've done this myself a couple of| times when I'm in a hurry.)|| Anyway, if the block device under the filesystem honestly does go away for| hotplug eject reasons, the obvious thing to do is umount -9 the sucker| immediately so userspace can collapse gracefully (or even conceivably| recover). The main difference here is that the flushing would all error out| and get discarded, and this wouldn't always get reported to the user, but| thanks to write cacheing that's the case anyway. (Use some variant of| O_DIRECT or fsync if you care.) The errors userspace does see switch from| "all my I/O failed with a media error" to "all my filehandles closed out from| under me" (and the directory I'm in has been deleted), but that's still| relatively logical behavior.|| Does this sound like it's off in left field?|| Rob