I don’t think I explained my point about changing these writes to
non-paging non-cached writes clearly enough.
I’m assuming that you don’t pass through all the cached operations to
FAT since that would cause the data to be double cached in memory. But,
normally, it is through these cached interfaces that FAT knows the file
size and valid data length are getting extended. Therefore, you’ve got
to translate paging IO actions from the cached IO to your file into a
set of actions which would have the same net affect for FAT (causing the
needed file extensions and valid data length extension).
It sounds like you are already managing the file length extensions. If
you send down a non-paging non-cached write, FAT allows that type of
write to extend valid data length and FAT internally manages all the
needed synchronization. FAT also allows the mapped page writer to
extend valid data length, but it expects some synchronization to already
be held. Right now, my guess is that FAT is interpreting your paging
write like it would a paging write from the mapped page writer (since it
doesn’t think you are the lazy writer) and therefore making incorrect
assumptions about what synchronization is already held as you haven’t
preacquire the same synchronization that the mapped page write does.
This could lead to intermittent corruption as the movement of valid data
length isn’t properly synchronized.
I’m confused by your statement that your only option is to zero the
middle range yourself. My understanding from your initial description
was that the range of the file getting zeroed previously had data
written to it and that data was overwritten with the incorrect zeros.
If you can make all the writes extend valid data length when they occur,
you won’t be in the case where you’ve written out correct data, but
valid data length didn’t get extended therefore the next write incorrect
zeros out the data between valid data length and your current write.
Regards,
Molly Brown
Microsoft Corporation
This posting is provided “AS IS” with no warranties and confers no
rights.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ladislav Zezula
Sent: Thursday, August 05, 2004 10:53 PM
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] Problems when the filter handles the cache
callbacks
Hi, Molly,
Thankyou for the answer.
while I guess you could reverse engineer where these function pointers
are in the shared cache map,
No, be sure that I won’t go this way. The problem that
I currently have is enough, I don’t need another ones :-))
FAT’s idea of ValidDataLength is getting out of sync with your
filter’s idea of ValidDataLength
Although the filter changed the EndOfFile value (by calling
IRP_MJ_SET+INFORMATION), the ValidDataLength
remains unchanged. The ValidDataLength changes later in the moment
when LazyWriter’s write completes.
Because I cannot change the ValidDataLength by any call
of IRP_MJ_SET_INFORMATION
(AFAIK, FileValidDataLengthInformation works on NTFS only)
I have to rely on Fastfat itself.
I think you have a couple options here. You could convert the lazy
writes to look like top-level non-cached user writes to the file.
This
Well, but this will not help. The problem occurs when
Fastfat assumes the write is NOT the LazyWriter. Changing
LazyWriter’s IRP to anything else will not change this.
If I change it to mapped write, the write will be rejected by FastFat.
(Paged writes behind the end of file are not allowed, right ?)
I think the (only) option will be to zero the middle space in the
filter by sending non-cached write IRPs. Although this solution hurts
me because of degraded performance.
Just one caveat here – I haven’t actually ever tried writing a filter
doing what you describe, so there may be some other problems here that
I’m not aware of :).
Heh, don’t even try it, unless you will have at least one year
of free time :-))). Anyway, thanks again for the answer.
L.
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com