Re: [PATCH] [RFC] Advanced TCA SCSI Disk Hotswap

[Randy.Dunlap]

On Sun, 27 Oct 2002, Rob Landley wrote:

(maybe wrap lines around column 70 ? :)

...

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