Re: Fast file writes without having large data flushes to disk



Hi Don,

thanks for this insight. I did not understand the different behaviour on
WRITE_THROUGH when used with NO_BUFFERING as opposed to using only
WRITE_THROUGH. I did not know that the Cache Manager is implemented by the
file system driver, I assumed that it's a separate component, and the lower
level drivers have other cache mechanisms, that are documented. For instance,
one cache would wait for some data to be written and perhaps expect that data
to be contiguous and so on.
About the Cache Manager, I would expect it to start flushing when the APIs
are called, or when a treshold has been reached. The thing is that, even
after the application finishes, the OS responsiveness is not totaly fluet -
perhaps due to lazy writes. During large transfers, sometimes it takes 10
seconds or more into a stall where there is no responsiveness from the
system, just disk activity; this is most likely an OS or disk driver
issue/bug.
It would seem that there is no way to prevent this short freeze. But could
it become longer? And are there tools that can show the amount of file system
cache?

Best regards,
Calin

"Don Burn" wrote:

Comments inline:

"Calin Iaru" <CalinIaru@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:911C9B4A-ED24-4375-A311-FE0AA0885C1F@xxxxxxxxxxxxxxxx
I am loking to chose the best file flags and APIs that would allow for
these bottlenecks to be fixed while maintaining a high write rate. For
once,
there's FlushFileBuffers() which can be called periodically, but I find
that
it inflicts a performance bottleneck and it can make the system less
responsive when this API is called.

Another alternative would be the
FILE_FLAG_NO_BUFFERING which disables caching; so far, tests are ok,
system
is responsive and I consider this option combined with
FILE_FLAG_OVERLAPPED.
One nuisance of FILE_FLAG_NO_BUFFERING is that writes can be only of
certain
multiple, so the file size must be a certain multiple; there are
solutions to
this, like reopening the file and appending the last buffer.

Or simply writing the last buffer full length then truncating the file
length with SetValidData, which will be a heck of a lot faster than the
method you suggest.

This post is more about the Cache Manager rather than file writes. So,
to
clarify this, I assume that there are more cache levels that are involved
in
writing a file. First, there's the OS cache, which is very fast and can
be
suppressed with FILE_FLAG_NO_BUFFERING.

The OS cache is the file system cache these are one and the same.

Then, there may be a file system
driver cache which is suppressed with FILE_FLAG_WRITE_THROUGH. For
instance,
if I don't use FILE_FLAG_WRITE_THROUGH, then the file system driver could
keep the writes and flush them later.

Wrong, the difference here is whether you want to know if the data is on
the disk, if you do this flag is needed. If all you care about is that the
disk driver has it queued then don't use this flag. Note: this flag can
slow things down alot.

Last cache level would be the disk
memory buffer that comes with most modern disks. It does not matter which
component caches the writes, it only matters that writes are not
cummulated
and flushed to the disk at once as the Cache Manager does.

The cache manager does not flush "at once" except when it is forced to, for
instance the file was cached, the that region is being accessed by a handle
with FILE_FLAG_NO_BUFFERING, and of couse by people who use
FlushFileBuffers(). Otherwise the cache manager uses lazy writes writing
pages that have not been referenced for a long time in the background.

If my assumption
is correct, then maybe the file system driver cache will flush the data
to
the disk when its own capacity has been reached. I assume that this is a
much
smaller block size, compared to the memory that the Cache Manager
allocates.

Your assumptions are very incorrect.

Perhaps it's better to use FILE_FLAG_WRITE_THROUGH or again
FlushFileBuffers(). This way, the data is reused by the Cache Manager, if
some application decides to read the same file. I expect
FILE_FLAG_WRITE_THROUGH to be slower than FlushFileBuffers(). I find the
documentation for FILE_FLAG_WRITE_THROUGH not very explicit nor clear.

You have chosen the worst of all worlds.



--
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply



.



Relevant Pages

  • Re: [PATCH 3/3, try #2] Blackfin: documents and maintainer patch
    ... This file contains the simple DMA Implementation for Blackfin ... +Please follow the steps to form the EXT3 File system and mount the same as root ... +There are only a few steps required to lock your code into the cache. ... - Requirements for mounting the root file system. ...
    (Linux-Kernel)
  • Re: SBS and use of cache
    ... > the inode cache is important for good performance. ... > using raw I/O (bypassing the file system). ... > Memory and Swap Space Utilization ...
    (microsoft.public.windows.server.sbs)
  • Re: what to do with "too much" RAM?
    ... > and such but the general rule is to NEVER cache writes. ... That depends what the raid controller and disk controllers ... > Think about server crash, power loss, file system integrity and do the math. ...
    (comp.unix.solaris)
  • Re: process memory and page cache clarification is needed
    ... Can we say that For directio (this is what i really use, ... If i use directio, instead of using page cache, the data is directly ... is necessary it can be paged out to swap disk. ... inside the page cahce which are dirty and hold file system data. ...
    (comp.unix.solaris)
  • Re: [PATCH 3/3, try #2] Blackfin: documents and maintainer patch
    ... This file contains the simple DMA Implementation for Blackfin ... +Please follow the steps to form the EXT3 File system and mount the same as root ... +There are only a few steps required to lock your code into the cache. ...
    (Linux-Kernel)

Quantcast