Hello all,
The Single instance storage functionality replaces copies of a file on a disk by a single copy in the “common store” and “link” files to the common store file in place of other copies. Further read accesses to the link file are directed to the common store file by the SIS filter. Writes are made to the link files.
I had a question regarding the handling of memory mapped files by single instance storage filter.The paper on SIS describes it as follows,
"Memory Mapped Access to SIS Links
Mapped file accesses present more of a challenge. When a user (or the system cache manager) maps a file and touches a page for the first time, it will generate a page fault which will be translated by the NT IO system into a read request that is sent to SIS. Read requests generated by page faults are specially marked, and the SIS filter can differentiate them from normal reads. Once SIS provides the data, the virtual memory system will map the appropriate page, and future accesses (either reads or writes) will not generate any action that will be seen by SIS. Other users who map and touch the same portion of the same file will be provided with a mapping to the same page, but the virtual memory system will not send a read to SIS, since it already has the data. The virtual memory system can unmap and throw away any clean (unwritten) pages without notifying SIS, and it will asynchronously generate writes for dirty pages at its own pace.
Because SIS cannot take any action when a mapped page is first written (because it doesn?t get any notification of the write), in order to maintain coherence mapped pages must be associated with the link file cache and not the common store; if not, then two users could map two different SIS links that share a common store file, and they would see each others changes, violating the basic SIS semantics. We were unwilling to change the NT memory manager to generate write faults when a page is first written.
Neither SIS?s clean nor dirty states provides correct behavior in the case of a page that has taken a mapped read fault. Treating pages that have seen page faults as clean would result in normal (ReadFile) reads to those pages going to the common store file, which violates the coherence of normal reads with mapped writes. Treating them as dirty causes another problem: if there has been no write to the page the virtual memory system will see the page as clean, and may discard it. Sending a read to such a page would result in the user seeing a zero-filled portion of the link file, which is clearly wrong. To handle this problem, SIS has a third page state, faulted. When a page is in the faulted state, it sends normal reads to the cache associated with the link file, and page-fault reads to the common store file. Since a page-fault read will only happen if the page has been discarded by the virtual memory manager, when one occurs SIS concludes that the page has not been written and so it is safe to use the data from the common store file. SIS directs all accesses (reads and writes, page-fault and normal) to dirty file regions to the link file."
The link to the full paper is
http://www.sagecertification.org/events/usenix-win2000/full_papers/bolosky/bolosky_html/index.html
What happens in the following scenario,
- there is a page faulted read request
- then there are some writes on that page, something which the SIS filter cannot detect
- that page is written to the disk by the virtual memory system
- now that the page is clean, it can be unmapped by the virtual memory system.
According to the paper, subsequent page faulted reads on this page would go to the store file i.e. the original file.
My questions are,
- Is this scenario possible?
- What do they mean by “mapped pages must be associated with the link file cache” ? Can a filter associate cache sections of one file to another file? If yes, how can it be done?
I am working on a mini-filter driver which would implement file system virtualization. I wish to implement similar functionality to avoid copy-on-write.
Thanks,
Nikhil.