question about VMM and memory mapped files

[Helen_Friedland]

Hi,

I was wondering if there’s a way for the file system driver to tell the Virtual Memory Manager not to hold a reference to the memory mapped file after it’s done with it, and instead send IRP_MJ_CLOSE right away.

Here is some background to the problem I’m trying to solve. We have our own file system, which acts as a network redirector that sends file system requests to the file server (using our own proprietary protocol). Currently, we do not implement any client-side caching, but we do provide support for memory mapped files. So the problem I’m facing is this. Say I ran an executable on the client. After it finished running, I want to recompile the same executable on the server. However, since the VMM on the client holds the reference to the file, the server has never received the close command, so the server has the file opened, so the compile fails because the complier cannot write to the file.

The only way I can think of to solve this problem is to add oplock support. So when the server receives the request from a client, it requests an oplock from the underlying FS, and when a 3rd party application (i.e. the compiler) tries to open the file for delete, I get the oplock break event and flush the image section of the file on the server, and then the 3rd party application can proceed.

Are there other ways of solving this problem? It seems that since oplocks are opportunistic, I am not quaranteed that the oplock will be granted, and if it is not, I’m back to square one.

Any advice is appreciated.

Thanks.
Helen.

---

Do you Yahoo!?
Get on board. You’re invited to try the new Yahoo! Mail Beta.

[Slava_Imameyev]

Hi,

MmFlushImageSection( …, MmFlushForWrite ) and CcPurgeCacheSection() delete segment objects for the executable and data image if no any maps exist. The file object is dereferenced then the segment is being deleted.

for example, the code from the fastfat:

Section = &Fcb->NonPaged->SectionObjectPointers;

DataSectionExists = (BOOLEAN)(Section->DataSectionObject != NULL);
ImageSectionExists = (BOOLEAN)(Section->ImageSectionObject != NULL);

//
// Note, it is critical to do the Image section first as the
// purge of the data section may cause the image section to go
// away, but the opposite is not true.
//

if (ImageSectionExists) {

(VOID)MmFlushImageSection( Section, MmFlushForWrite );
}

if (DataSectionExists) {

CcPurgeCacheSection( Section, NULL, 0, FALSE );
}

–
Slava Imameyev, xxxxx@hotmail.com

“Helen Friedland” wrote in message news:xxxxx@ntfsd…
Hi,

I was wondering if there’s a way for the file system driver to tell the Virtual Memory Manager not to hold a reference to the memory mapped file after it’s done with it, and instead send IRP_MJ_CLOSE right away.

Here is some background to the problem I’m trying to solve. We have our own file system, which acts as a network redirector that sends file system requests to the file server (using our own proprietary protocol). Currently, we do not implement any client-side caching, but we do provide support for memory mapped files. So the problem I’m facing is this. Say I ran an executable on the client. After it finished running, I want to recompile the same executable on the server. However, since the VMM on the client holds the reference to the file, the server has never received the close command, so the server has the file opened, so the compile fails because the complier cannot write to the file.

The only way I can think of to solve this problem is to add oplock support. So when the server receives the request from a client, it requests an oplock from the underlying FS, and when a 3rd party application (i.e. the compiler) tries to open the file for delete, I get the oplock break event and flush the image section of the file on the server, and then the 3rd party application can proceed.

Are there other ways of solving this problem? It seems that since oplocks are opportunistic, I am not quaranteed that the oplock will be granted, and if it is not, I’m back to square one.

Any advice is appreciated.

Thanks.
Helen.

------------------------------------------------------------------------------
Do you Yahoo!?
Get on board. You’re invited to try the new Yahoo! Mail Beta.

[Helen_Friedland]

Slava,

Thanks for the reply. I understand that I need to call MmFlushImageSection() to flush the image section, but that wasn’t my question.

Let me try to explain the architecture a little bit better. I have a client machine which is running my FS driver. The FS driver instead of going to the disk of the client machine, goes to the server machine. I.e. none of the files are local to the client. They are all on the server. On the server, I have my own file server running that serves the requests that come from my driver. (They use a proprietary protocol for communication). The way the server does file operations – it just calls Win32 File IO APIs to the underlying file system (NTFS).

The problem arises when a 3rd party application is trying to open a file on the server machine. The 3rd party application does not use my file server, it goes directly to the NTFS. Since my file server is bypassed, I have no idea that someone else is trying to open the file. However, the 3rd party’s file open doesn’t succeed because the file server has the file opened, since it never received the close command from the client, since the client still has the file opened because the VMM holds the reference to it.

I guess my question is, how is this handled on other networking/distributed systems? In CIFS/NTFS world, if I run an executable that sits on the mapped drive on one machine, and then compile it on another, it works. So somehow, the VMM gets flushed. How is that implemented?

Thanks.
Helen.

Slava Imameyev wrote: Hi,

MmFlushImageSection( …, MmFlushForWrite ) and CcPurgeCacheSection() delete segment objects for the executable and data image if no any maps exist. The file object is dereferenced then the segment is being deleted.

for example, the code from the fastfat:

Section = &Fcb->NonPaged->SectionObjectPointers;

DataSectionExists = (BOOLEAN)(Section->DataSectionObject != NULL);
ImageSectionExists = (BOOLEAN)(Section->ImageSectionObject != NULL);

//
// Note, it is critical to do the Image section first as the
// purge of the data section may cause the image section to go
// away, but the opposite is not true.
//

if (ImageSectionExists) {

(VOID)MmFlushImageSection( Section, MmFlushForWrite );
}

if (DataSectionExists) {

CcPurgeCacheSection( Section, NULL, 0, FALSE );
}

–
Slava Imameyev, xxxxx@hotmail.com

“Helen Friedland” wrote in message news:xxxxx@ntfsd…
Hi,

I was wondering if there’s a way for the file system driver to tell the Virtual Memory Manager not to hold a reference to the memory mapped file after it’s done with it, and instead send IRP_MJ_CLOSE right away.

Here is some background to the problem I’m trying to solve. We have our own file system, which acts as a network redirector that sends file system requests to the file server (using our own proprietary protocol). Currently, we do not implement any client-side caching, but we do provide support for memory mapped files. So the problem I’m facing is this. Say I ran an executable on the client. After it finished running, I want to recompile the same executable on the server. However, since the VMM on the client holds the reference to the file, the server has never received the close command, so the server has the file opened, so the compile fails because the complier cannot write to the file.

The only way I can think of to solve this problem is to add oplock support. So when the server receives the request from a client, it requests an oplock from the underlying FS, and when a 3rd party application (i.e. the compiler) tries to open the file for delete, I get the oplock break event and flush the image section of the file on the server, and then the 3rd party application can proceed.

Are there other ways of solving this problem? It seems that since oplocks are opportunistic, I am not quaranteed that the oplock will be granted, and if it is not, I’m back to square one.

Any advice is appreciated.

Thanks.
Helen.

---------------------------------
Do you Yahoo!?
Get on board. You’re invited to try the new Yahoo! Mail Beta.
—
Questions? First check the IFS FAQ at https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

[OSR_Community_User]

Helen,

You can call MmFlushImageSection from within IRP_MJ_CLEANUP handler. If the
section object is already closed then MmFlushImageSection succeeds and memory
manager releases reference to the file object. If section object is still
exists it is not safe to overwrite file on the server side.

Alexei.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Helen Friedland
Sent: Friday, August 18, 2006 11:04 AM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] question about VMM and memory mapped files

Slava,

Thanks for the reply. I understand that I need to call MmFlushImageSection()
to flush the image section, but that wasn’t my question.

Let me try to explain the architecture a little bit better. I have a client
machine which is running my FS driver. The FS driver instead of going to the
disk of the client machine, goes to the server machine. I.e. none of the
files are local to the client. They are all on the server. On the server, I
have my own file server running that serves the requests that come from my
driver. (They use a proprietary protocol for communication). The way the
server does file operations – it just calls Win32 File IO APIs to the
underlying file system (NTFS).

The problem arises when a 3rd party application is trying to open a file on
the server machine. The 3rd party application does not use my file server, it
goes directly to the NTFS. Since my file server is bypassed, I have no idea
that someone else is trying to open the file. However, the 3rd party’s file
open doesn’t succeed because the file server has the file opened, since it
never received the close command from the client, since the client still has
the file opened because the VMM holds the reference to it.

I guess my question is, how is this handled on other networking/distributed
systems? In CIFS/NTFS world, if I run an executable that sits on the mapped
drive on one machine, and then compile it on another, it works. So somehow,
the VMM gets flushed. How is that implemented?

Thanks.
Helen.

Slava Imameyev wrote:

Hi,

MmFlushImageSection( …, MmFlushForWrite ) and CcPurgeCacheSection() delete
segment objects for the executable and data image if no any maps exist. The
file object is dereferenced then the segment is being deleted.

for example, the code from the fastfat:

Section = &Fcb->NonPaged->SectionObjectPointers;

DataSectionExists = (BOOLEAN)(Section->DataSectionObject !=
NULL);
ImageSectionExists = (BOOLEAN)(Section->ImageSectionObject !=
NULL);

//
// Note, it is critical to do the Image section first as the
// purge of the data section may cause the image section to go
// away, but the opposite is not true.
//

if (ImageSectionExists) {

(VOID)MmFlushImageSection( Section, MmFlushForWrite );
}

if (DataSectionExists) {

CcPurgeCacheSection( Section, NULL, 0, FALSE );
}

–
Slava Imameyev, xxxxx@hotmail.com

“Helen Friedland” < xxxxx@yahoo.com> wrote in message news:xxxxx@ntfsd…
Hi,

I was wondering if there’s a way for the file system driver to tell the
Virtual Memory Manager not to hold a reference to the memory mapped file
after it’s done with it, and instead send IRP_MJ_CLOSE right away.

Here is some background to the problem I’m trying to solve. We have our own
file system, which acts as a network redirector that sends file system
requests to the file server (using our own proprietary protocol). Currently,
we do not implement any client-side caching, but we do provide support for
memory mapped files. So the problem I’m facing is this. Say I ran an
executable on the client. After it finished running, I want to recompile the
same executable on the server. However, since the VMM on the client holds the
reference to the file, the server has never received the close command, so
the server has the file opened, so the compile fails because the complier
cannot write to the file.

The only way I can think of to solve this problem is to add oplock support.
So when the server receives the request from a client, it requests an oplock
from the underlying FS, and when a 3rd party application (i.e. the compiler)
tries to open the file for delete, I get the oplock break event and flush the
image section of the file on the server, and then the 3rd party application
can proceed.

Are there other ways of solving this problem? It seems that since oplocks are
opportunistic, I am not quaranteed that the oplock will be granted, and if it
is not, I’m back to square one.

Any advice is appreciated.

Thanks.
Helen.



Do you Yahoo!?
Get on board. You’re
http:isers> invited to try the new Yahoo! Mail Beta.

—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

_____________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com — Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17 You are currently subscribed to
ntfsd as: xxxxx@vmware.com To unsubscribe send a blank email to
xxxxx@lists.osr.com</http:>

[Slava_Imameyev]

>So somehow, the VMM gets flushed

Pages are flushed( for data segments ) but not purged( for data and image segments ) if some user’s application maps the file, it is impossible in the Windows world w/o traversing all PTEs table for all processes.

If you use some sort of lock which allows you to write in the file on the server while the file is mapped by the client as a data section then there is no coherency in data( all FSDs put up with this ), if the file is mapped as an image then client’s application will definitely crash on the next page fault.

If client’s handles count becomes zero and there is no valid user’s image sections and data sections then the data coherence with the user’s applications on this node will be preserved if all pages are flushed and purged.

Be prepared to receive IRP_MJ_CLOSE from the MmFlushImageSection and CcPurgeCacheSection.

–
Slava Imameyev, xxxxx@hotmail.com

“Helen Friedland” wrote in message news:xxxxx@ntfsd…
Slava,

Thanks for the reply. I understand that I need to call MmFlushImageSection() to flush the image section, but that wasn’t my question.

Let me try to explain the architecture a little bit better. I have a client machine which is running my FS driver. The FS driver instead of going to the disk of the client machine, goes to the server machine. I.e. none of the files are local to the client. They are all on the server. On the server, I have my own file server running that serves the requests that come from my driver. (They use a proprietary protocol for communication). The way the server does file operations – it just calls Win32 File IO APIs to the underlying file system (NTFS).

The problem arises when a 3rd party application is trying to open a file on the server machine. The 3rd party application does not use my file server, it goes directly to the NTFS. Since my file server is bypassed, I have no idea that someone else is trying to open the file. However, the 3rd party’s file open doesn’t succeed because the file server has the file opened, since it never received the close command from the client, since the client still has the file opened because the VMM holds the reference to it.

I guess my question is, how is this handled on other networking/distributed systems? In CIFS/NTFS world, if I run an executable that sits on the mapped drive on one machine, and then compile it on another, it works. So somehow, the VMM gets flushed. How is that implemented?

Thanks.
Helen.

Slava Imameyev wrote:
Hi,

MmFlushImageSection( …, MmFlushForWrite ) and CcPurgeCacheSection() delete segment objects for the executable and data image if no any maps exist. The file object is dereferenced then the segment is being deleted.

for example, the code from the fastfat:

Section = &Fcb->NonPaged->SectionObjectPointers;

DataSectionExists = (BOOLEAN)(Section->DataSectionObject != NULL);
ImageSectionExists = (BOOLEAN)(Section->ImageSectionObject != NULL);

//
// Note, it is critical to do the Image section first as the
// purge of the data section may cause the image section to go
// away, but the opposite is not true.
//

if (ImageSectionExists) {

(VOID)MmFlushImageSection( Section, MmFlushForWrite );
}

if (DataSectionExists) {

CcPurgeCacheSection( Section, NULL, 0, FALSE );
}

–
Slava Imameyev, xxxxx@hotmail.com

“Helen Friedland” wrote in message news:xxxxx@ntfsd…
Hi,

I was wondering if there’s a way for the file system driver to tell the Virtual Memory Manager not to hold a reference to the memory mapped file after it’s done with it, and instead send IRP_MJ_CLOSE right away.

Here is some background to the problem I’m trying to solve. We have our own file system, which acts as a network redirector that sends file system requests to the file server (using our own proprietary protocol). Currently, we do not implement any client-side caching, but we do provide support for memory mapped files. So the problem I’m facing is this. Say I ran an executable on the client. After it finished running, I want to recompile the same executable on the server. However, since the VMM on the client holds the reference to the file, the server has never received the close command, so the server has the file opened, so the compile fails because the complier cannot write to the file.

The only way I can think of to solve this problem is to add oplock support. So when the server receives the request from a client, it requests an oplock from the underlying FS, and when a 3rd party application (i.e. the compiler) tries to open the file for delete, I get the oplock break event and flush the image section of the file on the server, and then the 3rd party application can proceed.

Are there other ways of solving this problem? It seems that since oplocks are opportunistic, I am not quaranteed that the oplock will be granted, and if it is not, I’m back to square one.

Any advice is appreciated.

Thanks.
Helen.

--------------------------------------------------------------------------
Do you Yahoo!?
Get on board. You’re invited to try the new Yahoo! Mail Beta.

—
Questions? First check the IFS FAQ at https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

[Helen_Friedland]

The VMM holds the reference to the Fcb (not the open handle), even after all user handles were closed (and all IRP_MJ_CLEANUP were called). On the very last IRP_MJ_CLEANUP request I see that fcb’s open handles count is 0, but the reference count is 1. If I try to MmFlushImageSection at this point, the call doesn’t succeed.

But then IRP_MJ_CLOSE never comes. The VMM does not let go of the reference to the fcb untill it has to reuse the memory (or so the Nagar’s book says). So even though the executable is done running, IRP_MJ_CLOSE doesn’t come.

It seems like other network FSDs have to deal with the same issues.

Slava Imameyev wrote: >So somehow, the VMM gets flushed

Pages are flushed( for data segments ) but not purged( for data and image segments ) if some user’s application maps the file, it is impossible in the Windows world w/o traversing all PTEs table for all processes.

If you use some sort of lock which allows you to write in the file on the server while the file is mapped by the client as a data section then there is no coherency in data( all FSDs put up with this ), if the file is mapped as an image then client’s application will definitely crash on the next page fault.

If client’s handles count becomes zero and there is no valid user’s image sections and data sections then the data coherence with the user’s applications on this node will be preserved if all pages are flushed and purged.

Be prepared to receive IRP_MJ_CLOSE from the MmFlushImageSection and CcPurgeCacheSection.

–
Slava Imameyev, xxxxx@hotmail.com

“Helen Friedland” wrote in message news:xxxxx@ntfsd…
Slava,

Thanks for the reply. I understand that I need to call MmFlushImageSection() to flush the image section, but that wasn’t my question.

Let me try to explain the architecture a little bit better. I have a client machine which is running my FS driver. The FS driver instead of going to the disk of the client machine, goes to the server machine. I.e. none of the files are local to the client. They are all on the server. On the server, I have my own file server running that serves the requests that come from my driver. (They use a proprietary protocol for communication). The way the server does file operations – it just calls Win32 File IO APIs to the underlying file system (NTFS).

The problem arises when a 3rd party application is trying to open a file on the server machine. The 3rd party application does not use my file server, it goes directly to the NTFS. Since my file server is bypassed, I have no idea that someone else is trying to open the file. However, the 3rd party’s file open doesn’t succeed because the file server has the file opened, since it never received the close command from the client, since the client still has the file opened because the VMM holds the reference to it.

I guess my question is, how is this handled on other networking/distributed systems? In CIFS/NTFS world, if I run an executable that sits on the mapped drive on one machine, and then compile it on another, it works. So somehow, the VMM gets flushed. How is that implemented?

Thanks.
Helen.

Slava Imameyev wrote: Hi,

MmFlushImageSection( …, MmFlushForWrite ) and CcPurgeCacheSection() delete segment objects for the executable and data image if no any maps exist. The file object is dereferenced then the segment is being deleted.

for example, the code from the fastfat:

Section = &Fcb->NonPaged->SectionObjectPointers;

DataSectionExists = (BOOLEAN)(Section->DataSectionObject != NULL);
ImageSectionExists = (BOOLEAN)(Section->ImageSectionObject != NULL);

//
// Note, it is critical to do the Image section first as the
// purge of the data section may cause the image section to go
// away, but the opposite is not true.
//

if (ImageSectionExists) {

(VOID)MmFlushImageSection( Section, MmFlushForWrite );
}

if (DataSectionExists) {

CcPurgeCacheSection( Section, NULL, 0, FALSE );
}

–
Slava Imameyev, xxxxx@hotmail.com

“Helen Friedland” wrote in message news:xxxxx@ntfsd…
Hi,

I was wondering if there’s a way for the file system driver to tell the Virtual Memory Manager not to hold a reference to the memory mapped file after it’s done with it, and instead send IRP_MJ_CLOSE right away.

Here is some background to the problem I’m trying to solve. We have our own file system, which acts as a network redirector that sends file system requests to the file server (using our own proprietary protocol). Currently, we do not implement any client-side caching, but we do provide support for memory mapped files. So the problem I’m facing is this. Say I ran an executable on the client. After it finished running, I want to recompile the same executable on the server. However, since the VMM on the client holds the reference to the file, the server has never received the close command, so the server has the file opened, so the compile fails because the complier cannot write to the file.

The only way I can think of to solve this problem is to add oplock support. So when the server receives the request from a client, it requests an oplock from the underlying FS, and when a 3rd party application (i.e. the compiler) tries to open the file for delete, I get the oplock break event and flush the image section of the file on the server, and then the 3rd party application can proceed.

Are there other ways of solving this problem? It seems that since oplocks are opportunistic, I am not quaranteed that the oplock will be granted, and if it is not, I’m back to square one.

Any advice is appreciated.

Thanks.
Helen.

---------------------------------
Do you Yahoo!?
Get on board. You’re invited to try the new Yahoo! Mail Beta.
—
Questions? First check the IFS FAQ at https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

—
Questions? First check the IFS FAQ at https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com


Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

[Slava_Imameyev]

>The VMM holds the reference to the Fcb

How to deal with this I answered in my first message. No other way to force the VMM to close image and data segment.

If I try to MmFlushImageSection at this point, the call doesn’t succeed

The reasons may be

1. There is opened image section, so the image segment can’t be deleted.
2. You call MmFlushImageSection with MmFlushForDelete and the file has been mapped as data and has at least one user’s section.

It seems like other network FSDs have to deal with the same issues.

All FSDs have to deal with this. The issue is the level of data coherence that FSD provides.

–
Slava Imameyev, xxxxx@hotmail.com

“Helen Friedland” wrote in message news:xxxxx@ntfsd…
The VMM holds the reference to the Fcb (not the open handle), even after all user handles were closed (and all IRP_MJ_CLEANUP were called). On the very last IRP_MJ_CLEANUP request I see that fcb’s open handles count is 0, but the reference count is 1. If I try to MmFlushImageSection at this point, the call doesn’t succeed.

But then IRP_MJ_CLOSE never comes. The VMM does not let go of the reference to the fcb untill it has to reuse the memory (or so the Nagar’s book says). So even though the executable is done running, IRP_MJ_CLOSE doesn’t come.

It seems like other network FSDs have to deal with the same issues.

Slava Imameyev wrote:
>So somehow, the VMM gets flushed

Pages are flushed( for data segments ) but not purged( for data and image segments ) if some user’s application maps the file, it is impossible in the Windows world w/o traversing all PTEs table for all processes.

If you use some sort of lock which allows you to write in the file on the server while the file is mapped by the client as a data section then there is no coherency in data( all FSDs put up with this ), if the file is mapped as an image then client’s application will definitely crash on the next page fault.

If client’s handles count becomes zero and there is no valid user’s image sections and data sections then the data coherence with the user’s applications on this node will be preserved if all pages are flushed and purged.

Be prepared to receive IRP_MJ_CLOSE from the MmFlushImageSection and CcPurgeCacheSection.

–
Slava Imameyev, xxxxx@hotmail.com

“Helen Friedland” wrote in message news:xxxxx@ntfsd…
Slava,

Thanks for the reply. I understand that I need to call MmFlushImageSection() to flush the image section, but that wasn’t my question.

Let me try to explain the architecture a little bit better. I have a client machine which is running my FS driver. The FS driver instead of going to the disk of the client machine, goes to the server machine. I.e. none of the files are local to the client. They are all on the server. On the server, I have my own file server running that serves the requests that come from my driver. (They use a proprietary protocol for communication). The way the server does file operations – it just calls Win32 File IO APIs to the underlying file system (NTFS).

The problem arises when a 3rd party application is trying to open a file on the server machine. The 3rd party application does not use my file server, it goes directly to the NTFS. Since my file server is bypassed, I have no idea that someone else is trying to open the file. However, the 3rd party’s file open doesn’t succeed because the file server has the file opened, since it never received the close command from the client, since the client still has the file opened because the VMM holds the reference to it.

I guess my question is, how is this handled on other networking/distributed systems? In CIFS/NTFS world, if I run an executable that sits on the mapped drive on one machine, and then compile it on another, it works. So somehow, the VMM gets flushed. How is that implemented?

Thanks.
Helen.

Slava Imameyev wrote:
Hi,

MmFlushImageSection( …, MmFlushForWrite ) and CcPurgeCacheSection() delete segment objects for the executable and data image if no any maps exist. The file object is dereferenced then the segment is being deleted.

for example, the code from the fastfat:

Section = &Fcb->NonPaged->SectionObjectPointers;

DataSectionExists = (BOOLEAN)(Section->DataSectionObject != NULL);
ImageSectionExists = (BOOLEAN)(Section->ImageSectionObject != NULL);

//
// Note, it is critical to do the Image section first as the
// purge of the data section may cause the image section to go
// away, but the opposite is not true.
//

if (ImageSectionExists) {

(VOID)MmFlushImageSection( Section, MmFlushForWrite );
}

if (DataSectionExists) {

CcPurgeCacheSection( Section, NULL, 0, FALSE );
}

–
Slava Imameyev, xxxxx@hotmail.com

“Helen Friedland” wrote in message news:xxxxx@ntfsd…
Hi,

I was wondering if there’s a way for the file system driver to tell the Virtual Memory Manager not to hold a reference to the memory mapped file after it’s done with it, and instead send IRP_MJ_CLOSE right away.

Here is some background to the problem I’m trying to solve. We have our own file system, which acts as a network redirector that sends file system requests to the file server (using our own proprietary protocol). Currently, we do not implement any client-side caching, but we do provide support for memory mapped files. So the problem I’m facing is this. Say I ran an executable on the client. After it finished running, I want to recompile the same executable on the server. However, since the VMM on the client holds the reference to the file, the server has never received the close command, so the server has the file opened, so the compile fails because the complier cannot write to the file.

The only way I can think of to solve this problem is to add oplock support. So when the server receives the request from a client, it requests an oplock from the underlying FS, and when a 3rd party application (i.e. the compiler) tries to open the file for delete, I get the oplock break event and flush the image section of the file on the server, and then the 3rd party application can proceed.

Are there other ways of solving this problem? It seems that since oplocks are opportunistic, I am not quaranteed that the oplock will be granted, and if it is not, I’m back to square one.

Any advice is appreciated.

Thanks.
Helen.

----------------------------------------------------------------------
Do you Yahoo!?
Get on board. You’re invited to try the new Yahoo! Mail Beta.

—
Questions? First check the IFS FAQ at https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com


Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

—
Questions? First check the IFS FAQ at https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com


Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

[Helen_Friedland]

Ok, I think I got it. Thanks for your help.

Slava Imameyev wrote: >The VMM holds the reference to the Fcb

How to deal with this I answered in my first message. No other way to force the VMM to close image and data segment.

>If I try to MmFlushImageSection at this point, the call doesn’t succeed

The reasons may be
1) There is opened image section, so the image segment can’t be deleted.
2) You call MmFlushImageSection with MmFlushForDelete and the file has been mapped as data and has at least one user’s section.

>It seems like other network FSDs have to deal with the same issues.

All FSDs have to deal with this. The issue is the level of data coherence that FSD provides.

–
Slava Imameyev, xxxxx@hotmail.com

“Helen Friedland” wrote in message news:xxxxx@ntfsd…
The VMM holds the reference to the Fcb (not the open handle), even after all user handles were closed (and all IRP_MJ_CLEANUP were called). On the very last IRP_MJ_CLEANUP request I see that fcb’s open handles count is 0, but the reference count is 1. If I try to MmFlushImageSection at this point, the call doesn’t succeed.

But then IRP_MJ_CLOSE never comes. The VMM does not let go of the reference to the fcb untill it has to reuse the memory (or so the Nagar’s book says). So even though the executable is done running, IRP_MJ_CLOSE doesn’t come.

It seems like other network FSDs have to deal with the same issues.

Slava Imameyev wrote: >So somehow, the VMM gets flushed

Pages are flushed( for data segments ) but not purged( for data and image segments ) if some user’s application maps the file, it is impossible in the Windows world w/o traversing all PTEs table for all processes.

If you use some sort of lock which allows you to write in the file on the server while the file is mapped by the client as a data section then there is no coherency in data( all FSDs put up with this ), if the file is mapped as an image then client’s application will definitely crash on the next page fault.

If client’s handles count becomes zero and there is no valid user’s image sections and data sections then the data coherence with the user’s applications on this node will be preserved if all pages are flushed and purged.

Be prepared to receive IRP_MJ_CLOSE from the MmFlushImageSection and CcPurgeCacheSection.

–
Slava Imameyev, xxxxx@hotmail.com

“Helen Friedland” wrote in message news:xxxxx@ntfsd…
Slava,

Thanks for the reply. I understand that I need to call MmFlushImageSection() to flush the image section, but that wasn’t my question.

Let me try to explain the architecture a little bit better. I have a client machine which is running my FS driver. The FS driver instead of going to the disk of the client machine, goes to the server machine. I.e. none of the files are local to the client. They are all on the server. On the server, I have my own file server running that serves the requests that come from my driver. (They use a proprietary protocol for communication). The way the server does file operations – it just calls Win32 File IO APIs to the underlying file system (NTFS).

The problem arises when a 3rd party application is trying to open a file on the server machine. The 3rd party application does not use my file server, it goes directly to the NTFS. Since my file server is bypassed, I have no idea that someone else is trying to open the file. However, the 3rd party’s file open doesn’t succeed because the file server has the file opened, since it never received the close command from the client, since the client still has the file opened because the VMM holds the reference to it.

I guess my question is, how is this handled on other networking/distributed systems? In CIFS/NTFS world, if I run an executable that sits on the mapped drive on one machine, and then compile it on another, it works. So somehow, the VMM gets flushed. How is that implemented?

Thanks.
Helen.

Slava Imameyev wrote: Hi,

MmFlushImageSection( …, MmFlushForWrite ) and CcPurgeCacheSection() delete segment objects for the executable and data image if no any maps exist. The file object is dereferenced then the segment is being deleted.

for example, the code from the fastfat:

Section = &Fcb->NonPaged->SectionObjectPointers;

DataSectionExists = (BOOLEAN)(Section->DataSectionObject != NULL);
ImageSectionExists = (BOOLEAN)(Section->ImageSectionObject != NULL);

//
// Note, it is critical to do the Image section first as the
// purge of the data section may cause the image section to go
// away, but the opposite is not true.
//

if (ImageSectionExists) {

(VOID)MmFlushImageSection( Section, MmFlushForWrite );
}

if (DataSectionExists) {

CcPurgeCacheSection( Section, NULL, 0, FALSE );
}

–
Slava Imameyev, xxxxx@hotmail.com

“Helen Friedland” wrote in message news:xxxxx@ntfsd…
Hi,

I was wondering if there’s a way for the file system driver to tell the Virtual Memory Manager not to hold a reference to the memory mapped file after it’s done with it, and instead send IRP_MJ_CLOSE right away.

Here is some background to the problem I’m trying to solve. We have our own file system, which acts as a network redirector that sends file system requests to the file server (using our own proprietary protocol). Currently, we do not implement any client-side caching, but we do provide support for memory mapped files. So the problem I’m facing is this. Say I ran an executable on the client. After it finished running, I want to recompile the same executable on the server. However, since the VMM on the client holds the reference to the file, the server has never received the close command, so the server has the file opened, so the compile fails because the complier cannot write to the file.

The only way I can think of to solve this problem is to add oplock support. So when the server receives the request from a client, it requests an oplock from the underlying FS, and when a 3rd party application (i.e. the compiler) tries to open the file for delete, I get the oplock break event and flush the image section of the file on the server, and then the 3rd party application can proceed.

Are there other ways of solving this problem? It seems that since oplocks are opportunistic, I am not quaranteed that the oplock will be granted, and if it is not, I’m back to square one.

Any advice is appreciated.

Thanks.
Helen.

---------------------------------
Do you Yahoo!?
Get on board. You’re invited to try the new Yahoo! Mail Beta.
—
Questions? First check the IFS FAQ at https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

—
Questions? First check the IFS FAQ at https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

—
Questions? First check the IFS FAQ at https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

---------------------------------
Stay in the know. Pulse on the new Yahoo.com. Check it out.

[OSR_Community_User]

> The only way I can think of to solve this problem is to add oplock support.
So

SMB uses oplocks for cache, not for user-mapped files. Oplock break cannot
force the file unmap, or even page invalidation of this pages.

It can only force cache flush, cache invalidation (only if there are no
user-mapped views), or immediate close of the file which is held non-closed due
to stale cache map referencing it (this is what the batch oplock break does).

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

[OSR_Community_User]

>MmFlushImageSection( …, MmFlushForWrite ) and CcPurgeCacheSection()

There is no MmPurgeImageSection, only flush.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

[OSR_Community_User]

>the VMM holds the reference to it.

I guess my question is, how is this handled on other networking/distributed
systems?

If the VMM has a reference to the file due to user-mapped view - then this is
not handled in Windows at all.

But, if the reference to the file object is held by the stale cache map with
zero refs on it, which is subject to some later destruction by Cc, and is
preserved only to speed up the subsequent MJ_CREATE/CcInitializeCacheMap to the
same file - then the batch oplock must be held by the client to do this, and
batch oplock break path in the client’s FSD shoud destroy this cache map (by
CcPurgeCacheSection+CcWaitForCurrentLazyWriterActivity I think).

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

[OSR_Community_User]

> The VMM holds the reference to the Fcb (not the open handle)

The VMM holds the reference to FILE_OBJECT used in MmCreateSection, which in
turn holds the reference to FCB (inside the FSD).

But then IRP_MJ_CLOSE never comes. The VMM does not let go of the

The VMM holds the reference to FILE_OBJECT till a) there are user-mapped views
OR b) there are cache maps.

Cache maps are derefed on MJ_CLEANUP in CcUninitializeCacheMap. The cache map
with zero refcount is not immediately destroyed, but is preserved to speed up
the possible next re-open of the same file. This requires the batch oplock, and
batch oplock break causes the FSD to kill this cache map immediately.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

[Slava_Imameyev]

>There is no MmPurgeImageSection, only flush.

Actually, MmFlushImageSection purges pages for an image segment and close it
if no image section object exists, it is no need to flush modified pages for
an image segment in a page file if no section object exists.

–
Slava Imameyev, xxxxx@hotmail.com

“Maxim S. Shatskih” wrote in message
news:xxxxx@ntfsd…
> >MmFlushImageSection( …, MmFlushForWrite ) and CcPurgeCacheSection()
>
> There is no MmPurgeImageSection, only flush.
>
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
>