RE: removable media support on 2.6.x

RE: removable media support on 2.6.x

[Jinu M.]

> 
> 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.

What we do with our 2.4 version of the driver is something on this
lines. When the media is removed we invalidate the buffers and then
set the card absent bit. Now on when read/write requests arrive we
return error status to the file system since card is absent. This worked
for 2.4.x.

Is there some existing driver which addresses removable media on 2.6.x
Kernel? I would like to see how it addresses this.. then I will have
a better idea to address it with the kernel support we have now.

-Jinu

RE: removable media support on 2.6.x

[Matthias Urlichs]

Hi, Jinu M. wrote:

> Is there some existing driver which addresses removable media on 2.6.x
> Kernel?

SCSI. USB sticks are SCSI disks in disguise; hotplugging works quite
well for them.

-- 
Matthias Urlichs

removable media support on 2.6.x

[Jinu M.]

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?

Thanks in advance,

-Jinu

Re: removable media support on 2.6.x

[Andrew Morton]

"Jinu M." <jinum@esntechnologies.co.in> 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.