Can you clarify your definition of “in use”. if a file is open on the volume, isn’t the device in use?
Is your definition of “in use” that the cache manger has flushed all dirty data, and no application has open handles. You might mark the device as removable, which gives some clues to other OS components that you might want to do the right thing to a remove request coming from above. You can also simulate the remove media eject button (like on a DVD drive) being pressed, although if a process has an open handle there is no guarantee this process will close the handle.
So, if the request to remove the device is coming from “below”, you may not have any option except to surprise remove the device, with preceding attempts to issue an eject.
There is a mechanism for applications to be notified that a device want’s to go away, but unfortunatly a lot of applications don’t register for this notification, so can’t participate in the graceful removal of a device.
One strategy is it’s up to user mode code to do whatever is needed to make a disk “not in use” before asking a virtual storport to remove a virtual disk.
If you mark the disk as removable, the OS changes it’s write flushing policy to not let stuff sit in memory too long, in which case some time limited wait for inactivity perhaps is a little more valid. There is also then OS support for a user to initiate a remove request.
As far as removing the devices when there are active pending requests, you could have a lock of some appropriate kind to prevent initiating a surprise removal when there are pending requests. On a more macro scale there is a facility called VSS that is used to coordinate when volumes are in an “application consistent” state. You can initiate a VSS snapshot request, and can be notified when all VSS aware components have flushed any dirty data.
Assuming you’re not doing any inappropriate reordering of write requests, a disk is always supposed to be in a “crash consistent” state, which mean if you surprise remove it, and then mount it again, from the viewpoint of things like file system metadata (but not file contents), the volume should always rollback to a consistent state. There are basically implicit synchronization fences delimited by returning the completion of a write. Each application has it’s own understanding of how these write completions imply an ordering. Thing like databases use great care to order writes such that the database can allows be opened in a transaction consistent state.
I suppose just like an application, a driver could open the disk for exclusive write, and if it is granted that lock, you can be sure nobody else is using the disk until you release the lock.
Given everything I’ve said, it seems like the two options are: just do surprise removal and expect crash consistent recovery to work as expected, or you must always successfully acquire an exclusive write lock on the disk you are about to remove. The exclusive write lock seems like the only method that’s guaranteed synchronized. You might somehow check there are no open files or the volume is not mounted, but after the check and before the disk is gone, something might access the disk, making your check no longer valid, and you have essentially just done a surprise removal.
Jan
On Oct 30, 2014, at 10:26 AM, Lloyd wrote:
>
> Hi,
>
> I am writing a virtual storport miniport driver. In this I wish to make sure that the mounted device is not under use when a remove request is received from the user. One approach I have tried is to, when a remove request is received, check whether any SCSI commands are coming from storport (for eg. for a period of 1second), and if no pending command is there, remove the device.
>
> While testing, I understood that this approach is flawed. Another approach I am thinking of is to check whether any file handle is open in the mounted device. Is there any mechanism to check it? or is there a better way to achieve my primary requirement?
>
> Thanks a lot,
> Lloyd
>
> — NTDEV is sponsored by OSR Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev OSR is HIRING!! See http://www.osr.com/careers For our schedule of WDF, WDM, debugging and other seminars visit: http://www.osr.com/seminars To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer