I've written another little tool for some simple tests of the Windows file cache:
FileCacheTest.
It writes to or reads from a file using different flags for for the Win32 API function
CreateFile.
Here is what the options apparently mean. All observations are made under XP SP2 and LargeFileCache=0
no flag:
Windows assumes nothing and works well.
FILE_FLAG_RANDOM_ACCESS:
Windows assumes random access and blows up the cache's working set aggressively and if required it swaps out your running applications unashamed to the pagefile. Later you can feel and hear how the app's memory is digged out of the pagefile, apparently without any read optimization. Vista's "ReadyBoost" will try to heal the symptoms...
For software developers: Use it very very carefully if you deal with large files!
FILE_FLAG_SEQUENTIAL_SCAN:
Windows assumes a sequential access. More read ahead buffer und read ahead is done even the previous accesses where not sequential. Not too much effect.
FILE_FLAG_NO_BUFFERING:
Windows does not use any file cache or buffering - by far the best way to read or write a file once. No buffering at all, the data is transferred directly from or to the buffer provided by the application (unless the file is NTFS compressed).
For software developers: The buffer has to be sector aligned, that's all. Todays hard drives have a sector size of 512 Bytes, CDs 2048 Bytes. You can check it by means of DeviceIoControl call with IOCTL_DISK_GET_DRIVE_GEOMETRY.
The easiest way is to get an aligned buffer is to use VirtualAlloc which provides 64K aligned memory, which should be good enough even for future hard drives with larger sectors. And you have to read or write complete sectors which might be difficult but it's worth!
FILE_FLAG_WRITE_THROUGH:
Writes goes thru the cache without buffering to the disk but data is stored in the cache too so following read accesses to the just written data come out of the cache.
Furthermore it shall request a write-through or immediate flush of the hard drives internal cache.
With 'flush at finish' the cache is flushed at the end of the write. If there is no write cache then the flush time is null or nearly null. This is the case on FAT formatted USB 'removable' drives, even with the removal policy 'Optimize for speed'. Since invented with XP this policy pretends to activate a write cache but this is true only on FAT formatted USB hard drives. On USB 'removable' drives the policies have no effect.
Only when the block size goes below 4096 Bytes write accesses on USB 'removable' drives are buffered. This way you can blow 20 MB of data into the write cache of a USB drive which is 'Optimized for fast removal'...
On NTFS formatted USB 'removable' drives the magic limit seems to be at 512 KB.
With "create and delete files" empty files are created and then deleted. This shows if write accesses to the file system are buffered or not.
|
