Re: removable media support on 2.6.x

[Andrew Morton]

"Jinu M." <jinum@xxxxxxxxxxxxxxxxxxxxx> wrote:
>
> Hi All,
> 
> We are developing a storage driver (block driver) on 2.6.x kernel. The 
> hardware we are using supports media removal on the fly. We are facing
> some problem when the media is removed while the disk is mounted. The
> system freezes and the module count never goes to zero.
> 
> This is what we do when the disk is removed on the fly.
> 
> disk_removed(...)
> {
> 	/* invalidate disk */
> 	if(gDisk->bdev) {
> 		invalidate_bdev(gDisk->bdev, 1);
> 		bdput(gDisk->bdev);
> 	}
> 
> 	/* indicates that no disk present */
> 	set_capacity(gDisk->gd, 0);
> 
> 	/* cleanup gendisk */
> 	del_gendisk(gDisk->gd);
> 	put_disk(gDisk->gd);
> 
> 	/* clean up blkqueue */
> 	blk_cleanup_queue(gDisk->blkqueue);
> }
> 
> disk_removed() is called from the workqueue that is initiated from the
> tasklet()<=isr() on card removal.
> 
> We guess invalidate_bdev() is the culprit ;) but would like to know
> from you all if we are doing some mistake. Is there something missing
> or something wrong in the way we are trying to provide removable media
> support?
> 

afaik we don't really support hot unplug like this.

Changes were made a few months ago (make the VFS use file->f_mapping rather
than file->f_dentry->d_inode->i_mapping) which set some of the pieces in
place but I think there's a way to go yet.

umm, the general idea is that when the disk vanishes your driver should
then return -EIO for all future I/O requests.  The block_device, the queue,
the inode and all that stuff remains in-core.

After device hot unplug we need to do <something> to disassociate the
defunct blockdev inode from the /dev/hdXX node.  I think <something> hasn't
been coded yet.

Later, someone puts in new media and you can then access that via /dev/hdXX
- you get a brand new inode, blockdev, queue, etc.  The old defunct one is
still alive, returning -EIO.

Eventually, all references to the old inode/blockdev/queue go away (due to
applications hitting EIO, etc).  The old mountpoint can be unmounted and
this drops the final ref, so the old inode/blockdev/queue get freed up.

As I say, I don't think all of this is implemented yet, but perhaps a lot
of it is.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/