Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S266055AbUFEEsr (ORCPT ); Sat, 5 Jun 2004 00:48:47 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S266045AbUFEEsr (ORCPT ); Sat, 5 Jun 2004 00:48:47 -0400 Received: from fw.osdl.org ([65.172.181.6]:9940 "EHLO mail.osdl.org") by vger.kernel.org with ESMTP id S264582AbUFEEsb (ORCPT ); Sat, 5 Jun 2004 00:48:31 -0400 Date: Fri, 4 Jun 2004 21:47:39 -0700 From: Andrew Morton To: "Jinu M." Cc: linux-kernel@vger.kernel.org, kernelnewbies@nl.linux.org, surendrai@esntechnologies.co.in Subject: Re: removable media support on 2.6.x Message-Id: <20040604214739.61232c26.akpm@osdl.org> In-Reply-To: <1118873EE1755348B4812EA29C55A9722AF016@esnmail.esntechnologies.co.in> References: <1118873EE1755348B4812EA29C55A9722AF016@esnmail.esntechnologies.co.in> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2444 Lines: 68 "Jinu M." 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 to disassociate the defunct blockdev inode from the /dev/hdXX node. I think 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/