Hi,
I developed a Native NT app that defragments NTFS metafiles directly - without using defragmentation API. Everything works properly for non system volumes - I lock them, dismount, and make changes to the file system.
It’s impossible to lock/dismount the system volume, so I just open it with FILE_SHARE_READ sharing flag, make changes to the file system, and reboot.
Now the problem is that even though I hold the volume handle open when calling NtShutdownSystem, the file system driver flushes some data from the cache to the disk and corrupts it. If I reset the system instead of calling NtShutdownSystem then the file system is OK.
My question is - how can I prevent file system driver from flushing the data? Autochk seems to do it some way, I disasmed it, but wasn’t able to find it doing anything special.
One example - I move $MFT, update $Boot to point to the new $MFT position, and after rebooting it points to the old $MFT position.
Thank you!
> It’s impossible to lock/dismount the system volume, so I just open it with
FILE_SHARE_READ sharing flag, make changes to >the file system, and
reboot.
Are you setting share write as well? I’d be surprised if you could open the
system volume on a live system without saying that you’ll share write. And
that would explain the behavior, you can’t assume that the FSD won’t change
the volume under you if you say that you’ll share write.
-scott
–
Scott Noone
Consulting Associate
OSR Open Systems Resources, Inc.
http://www.osronline.com
wrote in message news:xxxxx@ntdev…
> Hi,
>
> I developed a Native NT app that defragments NTFS metafiles directly -
> without using defragmentation API. Everything works properly for non
> system volumes - I lock them, dismount, and make changes to the file
> system.
>
> It’s impossible to lock/dismount the system volume, so I just open it with
> FILE_SHARE_READ sharing flag, make changes to the file system, and reboot.
>
> Now the problem is that even though I hold the volume handle open when
> calling NtShutdownSystem, the file system driver flushes some data from
> the cache to the disk and corrupts it. If I reset the system instead of
> calling NtShutdownSystem then the file system is OK.
>
> My question is - how can I prevent file system driver from flushing the
> data? Autochk seems to do it some way, I disasmed it, but wasn’t able to
> find it doing anything special.
>
> One example - I move $MFT, update $Boot to point to the new $MFT position,
> and after rebooting it points to the old $MFT position.
>
> Thank you!
>
>
Scott,
I do open the system volume with read sharing only - note that I do it from within Native NT app that allows such behaviour. Autochk does the same. The problem is that file system seems to flush its cache after I’m calling NtShutdownSystem to reboot the OS. I’m looking for a way to prevent that flush to occur.
I guess the question would be why this isn’t an issue for autochk. Do you
see the flushing occur there as well?
-scott
–
Scott Noone
Consulting Associate
OSR Open Systems Resources, Inc.
http://www.osronline.com
wrote in message news:xxxxx@ntdev…
> Scott,
>
> I do open the system volume with read sharing only - note that I do it
> from within Native NT app that allows such behaviour. Autochk does the
> same. The problem is that file system seems to flush its cache after I’m
> calling NtShutdownSystem to reboot the OS. I’m looking for a way to
> prevent that flush to occur.
>
>
>
My question is - how can I prevent file system driver from flushing
the data?
Autochk seems to do it some way, I disasmed it, but wasn’t able to
find it
doing anything special.
Autochk probably does it before the filesystem is mounted.
If you somehow manage to do this (hard reset without filesystem sync),
the user will still be treated to a “last shutdown was unexpected”
message on the next boot if it was the system drive.
James
> Autochk probably does it before the filesystem is mounted.
The FS is indeed mounted at that point. A volume open without
FILE_SHARE_WRITE set though is treated as an implicit volume lock, the FSD
will not allow the create to succeed if there are any outstanding file
objects to the volume that were opened with write or delete access.
-scott
–
Scott Noone
Consulting Associate
OSR Open Systems Resources, Inc.
http://www.osronline.com
“James Harper” wrote in message
news:xxxxx@ntdev…
>>
>> My question is - how can I prevent file system driver from flushing
> the data?
>> Autochk seems to do it some way, I disasmed it, but wasn’t able to
> find it
>> doing anything special.
>>
>
> Autochk probably does it before the filesystem is mounted.
>
> If you somehow manage to do this (hard reset without filesystem sync),
> the user will still be treated to a “last shutdown was unexpected”
> message on the next boot if it was the system drive.
>
> James
>
OK, the problem is solved!
Before making changes to the file system I was calling NtFsControlFile with FSCTL_IS_VOLUME_DIRTY control code. It turned out that is I remove that call then no file system buffer flush occurs during system reboot.
Frankly I’m not sure about the mechanism of this phenomenon. Any ideas?
According to FASTFAT, this is all that FAT does for that FSCTL:
//
// Verify the Vcb. We want to make double sure that this volume
// is around so that we know our information is good.
//
FatVerifyVcb( IrpContext, Vcb );
//
// Now set the returned information. We can avoid probing the disk
since
// we know our internal state is in sync.
//
if ( FlagOn(Vcb->VcbState, VCB_STATE_FLAG_VOLUME_DIRTY |
VCB_STATE_FLAG_MOUNTED_DIRTY) ) {
SetFlag( *VolumeState, VOLUME_IS_DIRTY );
}
Irp->IoStatus.Information = sizeof( ULONG );
FatCompleteRequest( IrpContext, Irp, STATUS_SUCCESS );
return STATUS_SUCCESS;
I’d suspect NTFS to be fairly similar which wouldn’t really explain the
behavior, though you’d need to observe it to confirm.
-scott
–
Scott Noone
Consulting Associate
OSR Open Systems Resources, Inc.
http://www.osronline.com
wrote in message news:xxxxx@ntdev…
> OK, the problem is solved!
>
> Before making changes to the file system I was calling NtFsControlFile
> with FSCTL_IS_VOLUME_DIRTY control code. It turned out that is I remove
> that call then no file system buffer flush occurs during system reboot.
> Frankly I’m not sure about the mechanism of this phenomenon. Any ideas?
>
>
>
Thank you Scott, I would expect NTFS to do something similar (just checking some flag), but I tested this multiple times - and indeed it’s FSCTL_IS_VOLUME_DIRTY call that later makes the file system to flush $MFT as soon as I call NtShutdownSystem.