Who is calling FastIoDetachDevice? I implement a reference counting scheme
when I increment a reference counter when sending IRP down to the FSD and
decrement on its way back in completion routine. But I imagined the next
scenario.
- I receive the last close on the volume. I increment the reference counter
and send the request down.
- FSD receives the request and decides to dismount. Let’s assume FSD is
FastFat. So FatCommonClose calls FatCheckForDismount in this case.
- When FatCheckForDismount calls IoDeleteDevice I receive
FastIoDetachDevice where I wait for all outstanding IO operations to finish.
But as soon as IRP_MJ_CLOSE is still not complete I end hanging.
So, does IO manager (or whoever else) handles such scenario well or I should
put my dismount code in some worker thread to allow the last request to
complete?
-htfv
IoDeleteDevice() which can be also called from ObDereferenceObject().
They start the fastiodetachdevice chain. If the device below you goes to
zero, you are going to get torn down. Best bet is to maintain your own
reference to the underlying device object if you want to assure this
will not happen; however, I suspect a little design revision may be in
order 
Jamey
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Alexey Logachyov
Sent: Friday, September 06, 2002 12:22 AM
To: File Systems Developers
Subject: [ntfsd] Removable media…
Who is calling FastIoDetachDevice? I implement a reference counting
scheme
when I increment a reference counter when sending IRP down to the FSD
and
decrement on its way back in completion routine. But I imagined the next
scenario.
- I receive the last close on the volume. I increment the reference
counter
and send the request down.
- FSD receives the request and decides to dismount. Let’s assume FSD is
FastFat. So FatCommonClose calls FatCheckForDismount in this case.
- When FatCheckForDismount calls IoDeleteDevice I receive
FastIoDetachDevice where I wait for all outstanding IO operations to
finish.
But as soon as IRP_MJ_CLOSE is still not complete I end hanging.
So, does IO manager (or whoever else) handles such scenario well or I
should
put my dismount code in some worker thread to allow the last request to
complete?
-htfv
You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
To unsubscribe send a blank email to %%email.unsub%%
Seem like I wasn’t clear enough. I do implement my own reference counter.
-htfv
----- Original Message -----
From: “Jamey Kirby”
To: “File Systems Developers”
Sent: Friday, September 06, 2002 10:37 AM
Subject: [ntfsd] RE: Removable media…
> IoDeleteDevice() which can be also called from ObDereferenceObject().
> They start the fastiodetachdevice chain. If the device below you goes to
> zero, you are going to get torn down. Best bet is to maintain your own
> reference to the underlying device object if you want to assure this
> will not happen; however, I suspect a little design revision may be in
> order
>
> Jamey
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Alexey Logachyov
> Sent: Friday, September 06, 2002 12:22 AM
> To: File Systems Developers
> Subject: [ntfsd] Removable media…
>
> Who is calling FastIoDetachDevice? I implement a reference counting
> scheme
> when I increment a reference counter when sending IRP down to the FSD
> and
> decrement on its way back in completion routine. But I imagined the next
> scenario.
> 1. I receive the last close on the volume. I increment the reference
> counter
> and send the request down.
> 2. FSD receives the request and decides to dismount. Let’s assume FSD is
> FastFat. So FatCommonClose calls FatCheckForDismount in this case.
> 3. When FatCheckForDismount calls IoDeleteDevice I receive
> FastIoDetachDevice where I wait for all outstanding IO operations to
> finish.
> But as soon as IRP_MJ_CLOSE is still not complete I end hanging.
>
> So, does IO manager (or whoever else) handles such scenario well or I
> should
> put my dismount code in some worker thread to allow the last request to
> complete?
>
> -htfv
>
>
>
>
>
> —
> You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to %%email.unsub%%
>
>
>
> —
> You are currently subscribed to ntfsd as: xxxxx@vba.com.by
> To unsubscribe send a blank email to %%email.unsub%%
>
For the target device object?
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Alexey Logachyov
Sent: Friday, September 06, 2002 1:28 AM
To: File Systems Developers
Subject: [ntfsd] RE: Removable media…
Seem like I wasn’t clear enough. I do implement my own reference
counter.
-htfv
----- Original Message -----
From: “Jamey Kirby”
To: “File Systems Developers”
Sent: Friday, September 06, 2002 10:37 AM
Subject: [ntfsd] RE: Removable media…
> IoDeleteDevice() which can be also called from ObDereferenceObject().
> They start the fastiodetachdevice chain. If the device below you goes
to
> zero, you are going to get torn down. Best bet is to maintain your own
> reference to the underlying device object if you want to assure this
> will not happen; however, I suspect a little design revision may be in
> order
>
> Jamey
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Alexey Logachyov
> Sent: Friday, September 06, 2002 12:22 AM
> To: File Systems Developers
> Subject: [ntfsd] Removable media…
>
> Who is calling FastIoDetachDevice? I implement a reference counting
> scheme
> when I increment a reference counter when sending IRP down to the FSD
> and
> decrement on its way back in completion routine. But I imagined the
next
> scenario.
> 1. I receive the last close on the volume. I increment the reference
> counter
> and send the request down.
> 2. FSD receives the request and decides to dismount. Let’s assume FSD
is
> FastFat. So FatCommonClose calls FatCheckForDismount in this case.
> 3. When FatCheckForDismount calls IoDeleteDevice I receive
> FastIoDetachDevice where I wait for all outstanding IO operations to
> finish.
> But as soon as IRP_MJ_CLOSE is still not complete I end hanging.
>
> So, does IO manager (or whoever else) handles such scenario well or I
> should
> put my dismount code in some worker thread to allow the last request
to
> complete?
>
> -htfv
>
>
>
>
>
> —
> You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to %%email.unsub%%
>
>
>
> —
> You are currently subscribed to ntfsd as: xxxxx@vba.com.by
> To unsubscribe send a blank email to %%email.unsub%%
>
—
You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
To unsubscribe send a blank email to %%email.unsub%%
Right, for target device object.
Every time I get an IRP I increment my own reference counter. I decrement
the counter on every IRP completion.
-htfv
----- Original Message -----
From: “Jamey Kirby”
To: “File Systems Developers”
Sent: Friday, September 06, 2002 10:38 PM
Subject: [ntfsd] RE: Removable media…
> For the target device object?
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Alexey Logachyov
> Sent: Friday, September 06, 2002 1:28 AM
> To: File Systems Developers
> Subject: [ntfsd] RE: Removable media…
>
> Seem like I wasn’t clear enough. I do implement my own reference
> counter.
>
> -htfv
>
> ----- Original Message -----
> From: “Jamey Kirby”
> To: “File Systems Developers”
> Sent: Friday, September 06, 2002 10:37 AM
> Subject: [ntfsd] RE: Removable media…
>
>
> > IoDeleteDevice() which can be also called from ObDereferenceObject().
> > They start the fastiodetachdevice chain. If the device below you goes
> to
> > zero, you are going to get torn down. Best bet is to maintain your own
> > reference to the underlying device object if you want to assure this
> > will not happen; however, I suspect a little design revision may be in
> > order
> >
> > Jamey
> >
> >
> > -----Original Message-----
> > From: xxxxx@lists.osr.com
> > [mailto:xxxxx@lists.osr.com] On Behalf Of Alexey Logachyov
> > Sent: Friday, September 06, 2002 12:22 AM
> > To: File Systems Developers
> > Subject: [ntfsd] Removable media…
> >
> > Who is calling FastIoDetachDevice? I implement a reference counting
> > scheme
> > when I increment a reference counter when sending IRP down to the FSD
> > and
> > decrement on its way back in completion routine. But I imagined the
> next
> > scenario.
> > 1. I receive the last close on the volume. I increment the reference
> > counter
> > and send the request down.
> > 2. FSD receives the request and decides to dismount. Let’s assume FSD
> is
> > FastFat. So FatCommonClose calls FatCheckForDismount in this case.
> > 3. When FatCheckForDismount calls IoDeleteDevice I receive
> > FastIoDetachDevice where I wait for all outstanding IO operations to
> > finish.
> > But as soon as IRP_MJ_CLOSE is still not complete I end hanging.
> >
> > So, does IO manager (or whoever else) handles such scenario well or I
> > should
> > put my dismount code in some worker thread to allow the last request
> to
> > complete?
> >
> > -htfv
> >
> >
> >
> >
> >
> > —
> > You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
> > To unsubscribe send a blank email to %%email.unsub%%
> >
> >
> >
> > —
> > You are currently subscribed to ntfsd as: xxxxx@vba.com.by
> > To unsubscribe send a blank email to %%email.unsub%%
> >
>
>
>
>
> —
> You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to %%email.unsub%%
>
>
>
> —
> You are currently subscribed to ntfsd as: xxxxx@vba.com.by
> To unsubscribe send a blank email to %%email.unsub%%
>
And, this reference count is actually updating the reference on the
target (i.e. ObReferenceObject(targetDevice);)?
Jamey
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Alexey Logachyov
Sent: Saturday, September 07, 2002 12:29 AM
To: File Systems Developers
Subject: [ntfsd] RE: Removable media…
Right, for target device object.
Every time I get an IRP I increment my own reference counter. I
decrement
the counter on every IRP completion.
-htfv
----- Original Message -----
From: “Jamey Kirby”
To: “File Systems Developers”
Sent: Friday, September 06, 2002 10:38 PM
Subject: [ntfsd] RE: Removable media…
> For the target device object?
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Alexey Logachyov
> Sent: Friday, September 06, 2002 1:28 AM
> To: File Systems Developers
> Subject: [ntfsd] RE: Removable media…
>
> Seem like I wasn’t clear enough. I do implement my own reference
> counter.
>
> -htfv
>
> ----- Original Message -----
> From: “Jamey Kirby”
> To: “File Systems Developers”
> Sent: Friday, September 06, 2002 10:37 AM
> Subject: [ntfsd] RE: Removable media…
>
>
> > IoDeleteDevice() which can be also called from
ObDereferenceObject().
> > They start the fastiodetachdevice chain. If the device below you
goes
> to
> > zero, you are going to get torn down. Best bet is to maintain your
own
> > reference to the underlying device object if you want to assure this
> > will not happen; however, I suspect a little design revision may be
in
> > order
> >
> > Jamey
> >
> >
> > -----Original Message-----
> > From: xxxxx@lists.osr.com
> > [mailto:xxxxx@lists.osr.com] On Behalf Of Alexey
Logachyov
> > Sent: Friday, September 06, 2002 12:22 AM
> > To: File Systems Developers
> > Subject: [ntfsd] Removable media…
> >
> > Who is calling FastIoDetachDevice? I implement a reference counting
> > scheme
> > when I increment a reference counter when sending IRP down to the
FSD
> > and
> > decrement on its way back in completion routine. But I imagined the
> next
> > scenario.
> > 1. I receive the last close on the volume. I increment the reference
> > counter
> > and send the request down.
> > 2. FSD receives the request and decides to dismount. Let’s assume
FSD
> is
> > FastFat. So FatCommonClose calls FatCheckForDismount in this case.
> > 3. When FatCheckForDismount calls IoDeleteDevice I receive
> > FastIoDetachDevice where I wait for all outstanding IO operations to
> > finish.
> > But as soon as IRP_MJ_CLOSE is still not complete I end hanging.
> >
> > So, does IO manager (or whoever else) handles such scenario well or
I
> > should
> > put my dismount code in some worker thread to allow the last request
> to
> > complete?
> >
> > -htfv
> >
> >
> >
> >
> >
> > —
> > You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
> > To unsubscribe send a blank email to %%email.unsub%%
> >
> >
> >
> > —
> > You are currently subscribed to ntfsd as: xxxxx@vba.com.by
> > To unsubscribe send a blank email to %%email.unsub%%
> >
>
>
>
>
> —
> You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to %%email.unsub%%
>
>
>
> —
> You are currently subscribed to ntfsd as: xxxxx@vba.com.by
> To unsubscribe send a blank email to %%email.unsub%%
>
—
You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
To unsubscribe send a blank email to %%email.unsub%%
Nope. Shoud it? If it does, please, explain the generic scenario of
dismounting (and implementation also).
-htfv
----- Original Message -----
From: “Jamey Kirby”
To: “File Systems Developers”
Sent: Saturday, September 07, 2002 11:47 PM
Subject: [ntfsd] RE: Removable media…
> And, this reference count is actually updating the reference on the
> target (i.e. ObReferenceObject(targetDevice);)?
>
> Jamey
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Alexey Logachyov
> Sent: Saturday, September 07, 2002 12:29 AM
> To: File Systems Developers
> Subject: [ntfsd] RE: Removable media…
>
> Right, for target device object.
>
> Every time I get an IRP I increment my own reference counter. I
> decrement
> the counter on every IRP completion.
>
> -htfv
>
> ----- Original Message -----
> From: “Jamey Kirby”
> To: “File Systems Developers”
> Sent: Friday, September 06, 2002 10:38 PM
> Subject: [ntfsd] RE: Removable media…
>
>
> > For the target device object?
> >
> >
> > -----Original Message-----
> > From: xxxxx@lists.osr.com
> > [mailto:xxxxx@lists.osr.com] On Behalf Of Alexey Logachyov
> > Sent: Friday, September 06, 2002 1:28 AM
> > To: File Systems Developers
> > Subject: [ntfsd] RE: Removable media…
> >
> > Seem like I wasn’t clear enough. I do implement my own reference
> > counter.
> >
> > -htfv
> >
> > ----- Original Message -----
> > From: “Jamey Kirby”
> > To: “File Systems Developers”
> > Sent: Friday, September 06, 2002 10:37 AM
> > Subject: [ntfsd] RE: Removable media…
> >
> >
> > > IoDeleteDevice() which can be also called from
> ObDereferenceObject().
> > > They start the fastiodetachdevice chain. If the device below you
> goes
> > to
> > > zero, you are going to get torn down. Best bet is to maintain your
> own
> > > reference to the underlying device object if you want to assure this
> > > will not happen; however, I suspect a little design revision may be
> in
> > > order
> > >
> > > Jamey
> > >
> > >
> > > -----Original Message-----
> > > From: xxxxx@lists.osr.com
> > > [mailto:xxxxx@lists.osr.com] On Behalf Of Alexey
> Logachyov
> > > Sent: Friday, September 06, 2002 12:22 AM
> > > To: File Systems Developers
> > > Subject: [ntfsd] Removable media…
> > >
> > > Who is calling FastIoDetachDevice? I implement a reference counting
> > > scheme
> > > when I increment a reference counter when sending IRP down to the
> FSD
> > > and
> > > decrement on its way back in completion routine. But I imagined the
> > next
> > > scenario.
> > > 1. I receive the last close on the volume. I increment the reference
> > > counter
> > > and send the request down.
> > > 2. FSD receives the request and decides to dismount. Let’s assume
> FSD
> > is
> > > FastFat. So FatCommonClose calls FatCheckForDismount in this case.
> > > 3. When FatCheckForDismount calls IoDeleteDevice I receive
> > > FastIoDetachDevice where I wait for all outstanding IO operations to
> > > finish.
> > > But as soon as IRP_MJ_CLOSE is still not complete I end hanging.
> > >
> > > So, does IO manager (or whoever else) handles such scenario well or
> I
> > > should
> > > put my dismount code in some worker thread to allow the last request
> > to
> > > complete?
> > >
> > > -htfv
> > >
> > >
> > >
> > >
> > >
> > > —
> > > You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
> > > To unsubscribe send a blank email to %%email.unsub%%
> > >
> > >
> > >
> > > —
> > > You are currently subscribed to ntfsd as: xxxxx@vba.com.by
> > > To unsubscribe send a blank email to %%email.unsub%%
> > >
> >
> >
> >
> >
> > —
> > You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
> > To unsubscribe send a blank email to %%email.unsub%%
> >
> >
> >
> > —
> > You are currently subscribed to ntfsd as: xxxxx@vba.com.by
> > To unsubscribe send a blank email to %%email.unsub%%
> >
>
>
>
>
> —
> You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to %%email.unsub%%
>
>
>
> —
> You are currently subscribed to ntfsd as: xxxxx@vba.com.by
> To unsubscribe send a blank email to %%email.unsub%%
>
> Who is calling FastIoDetachDevice?
IoDeleteDevice calls it, if the dying device has something attached to
it.
Usually, for FS filter, it is OK to rely on FastIoDetachDevice to
delete its device objects. Do not call IoDeleteDevice for filter
devices in other places.
Max