You wouldn’t find anything out about this for
MapViewOfSection/MapViewOfFile since those aren’t using the system cache
virtual address space. Mm has dedicated about 500MB of kernel VA from
(0xc100000 on up) for the exclusive use of Cc; in usermode you have your
own 2GB of address space and no length restrictions, and in kernel mode
the regular file mapping APIs will use another swatch of VA which, while
it has no length restrictions, is free to fail if it is full or
fragmented.
If this isn’t called out in the new Cc API docs its my fault for not
realizing it on review and I’ll see if I can get that updated. I’m
certain Nagar talks about this in his book, though I don’t have my copy
handy.
By the way, the right way to think about this is a flat array of 256k
buckets being overlaid on the file starting at byte 0. The states those
buckets can be in are binary, either mapped or not depending on whether
there are any map/pin requests within those buckets. As a practical
matter, if you map 0x1000 bytes at offset 0x5000 in a file, you will get
back a buffer virtual address like 0xc1045000 but beneath you the entire
0x40000 byte view was mapped from 0xc1000000 to 0xc103ffff in the course
of satisfying the request. (please interpret none of this as indicating
it is a good idea to step outside of the range you indicated you mapped;
when you use these APIs, Cc tickles Mm into making sure it doesn’t read
pages outside the range you are asking for)
And, if you map bytes at offset 256k you may wind up with a virtual
address like 0xd40c0000; i.e., quite non-adjacent.
-----Original Message-----
From: xxxxx@omnishift.com
[mailto:xxxxx@omnishift.com]
Sent: Friday, April 27, 2001 8:16 AM
To: File Systems Developers
Subject: [ntfsd] RE: Problems with CcMapData()
Thanks very much, Daniel! Other experiments were leading me to
believe that there was something special about the 256K boundary.
So naturally, I’m wondering how I should have known about this.
The documentation for ZwMapViewOfSection() (and the Win32
MapViewOfFile(), for that matter) mentions that the file offset will be
rounded down to the allocation granularity. But it doesn’t say anything
about the size of the mapped view – just that it’s rounded up to the
next page size. And in particular, nothing I have read about the
pinning interface suggested this limitation.
Can you point me to somewhere in the documentation where this is
spelled out?
Thanks again,
Curt
-----Original Message-----
From: Daniel Lovinger
[mailto:xxxxx@Exchange.Microsoft.com]
Sent: Thursday, April 26, 2001 11:36 AM
To: File Systems Developers
Subject: [ntfsd] RE: Problems with CcMapData()
You can’t map across view boundaries in the cache
manager. The views we’re managing from Mm are 256k in size, and define
the maximum amount (and alignment) of a file that you can access with a
single mapping operation.
0 -> 256k
256k -> 512k
4k -> 7.5k
etc., not
254k -> 258k
500k -> 1024k
This is what VACB_MAPPING_GRANULARITY is in ntifs.h.
Your offset and length below imply your crossing the boundary between
the first and second view of the file, and when CcMapData touches those
pages (after mapping the view) it crosses the view boundary and touches
presumeably unmapped virtual addresses. There are no safety checks in Cc
and the VA it returns is simply the VA for the first offset you request.
It would be a great candidate for a future extension to the verifier.
Cc/Mm work like this to avoid the heap-management style
problems that would result if we had to allow arbitrarily large mappings
to occur within the fixed VA space. We can’t allow the space to
fragment.
Yes, this does imply unnatural buffering gyrations if
you have structures in the file that cross the boundary. Some of the
trickiest code I’ve written was in the directory stream handling of the
UDF filesystem driver to handle exactly that.
-----Original Message-----
From: xxxxx@omnishift.com
[mailto:xxxxx@omnishift.com]
Sent: Thursday, April 26, 2001 10:59 AM
To: File Systems Developers
Subject: [ntfsd] Problems with CcMapData()
Hi all:
I’ve been using CcMapData() in my FSD for months
(following the example in the fastfat sources), and it has always seemed
to work for me, until recently. I’m now seeing a problem that I’m
hoping someone can enlighten me on.
I’m running on the free build of W2K (not sure
which build version).
I’m getting a bug check in a routine called by
CcMapData() (the call to KeBugCheck() is at
MmTrimAllSystemPagableMemory+0x47ef) when I call CcMapData(). I have no
idea why. I’m doing this to manage directory file contents; I’ve
created a FO with IoCreateStreamFileObject(), and successfully call
CcMapData() for the first 64 4K pages from the directory. But on the
65th page read (e.g., offset = 0x3ff3c, length = 0xf4), CcMapData()
calls the routine above that bug checks, with a
PAGE_FAULT_IN_NONPAGED_AREA. And sure enough, the address being
referenced isn’t valid.
All the “good” calls to CcMapData() turn around
and call my FSD to do a non-cached read, which I complete successfully.
The 65th call to CcMapData(), though, never recurses back into my FSD –
it just blows up.
I have checked numerous times as to the state of
the FCB header’s AllocationSize value, and it is more than large enough.
The directory file size doesn’t change; and when I call
CcInitiailzeCacheMap() on the FO, its size covers the range I’m
ultimately trying to map into the cache.
Given the simple interface to CcMapData(), I’m
at a loss to understand what I can be doing wrong. Ideas?
I did spend some time stepping through the code
in MmTrim… from the call in CcMapData() to the bug check, and have
found where the “good” and “bad” calls to CcMapData() diverge; however,
not understanding what I assume are the NT cache manager’s data
structures, I can’t glean any insights from this.
Thanks in advance for any help you can provide.
Curt Wohlgemuth
You are currently subscribed to ntfsd as:
xxxxx@exchange.microsoft.com
To unsubscribe send a blank email to
leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
You are currently subscribed to ntfsd as:
xxxxx@omnishift.com
To unsubscribe send a blank email to
leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
You are currently subscribed to ntfsd as:
xxxxx@exchange.microsoft.com
To unsubscribe send a blank email to
leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com