The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

CIFS WriteFile performance *awful*

hFile = CreateFile(...,"Z:\\foo.txt",...);
for (i=0; i < foo[i]; i++)
    WriteFile(hFile,foo[i]->record,...);

If Z: drive was mapped CIFS, the performance of that code over is just awful.  It appears Windows does no buffering *whatsoever*  When you tell an application that is used to using the local filesystem hit the network filesystem, suddenly performance falls through the floor because the CIFS implementation appears to do no local write buffering.

I don't get it, the UNIX world rarely uses file locking so you can't get away with that, but in Windows every application seems to have an exclusive write-lock on their work files -- it seems to happen by default.  So why NOT do aggressive local file caching?

Is CIFS performance just terrible because no one decided to implement a write buffer?
Michael B
Friday, August 26, 2005
 
 
I was expecting a preview before submitting that....  Let me revise.
----

hFile = CreateFile(...,"Z:\\foo.txt",...);
for (i=0; foo[i]; i++)
    WriteFile(hFile,foo[i]->record,...);

If Z: drive was mapped as CIFS, the performance of that code is just awful.  It appears Windows does no local buffering *whatsoever*  the client waits for the server to ack each write.  Yes, I can fix this by doing my own buffering, but there's a deeper concern.

When you tell an application that is used to using the local filesystem to hit a network filesystem, suddenly performance falls through the floor because the CIFS implementation isn't doing write buffering.  If someone hadn't tested the application over CIFS beforehand, it's probably going to be slow.

I don't get it, the UNIX world rarely uses file locking so NFS can't get away with doing that, but in Windows every application seems to have an exclusive write-lock on their work files by default, so why NOT do aggressive local file caching over CIFS?

Sure, you risk having an inconsistent file on the server if the client crashes halfway through the write, but this doesn't seem to be a big concern in the Windows world since there's no way to do a stable file update locally ANYWAY -- application developers can't avoid this case locally even if they want to.

Is CIFS performance just terrible because no one decided to implement a write buffer?

(How do you implement ACID databases on Windows anyway? Do you open a file in direct mode and use synchronous writes or what?)
Michael B
Friday, August 26, 2005
 
 
Dunno about CIFS, but Unix/NFS is similar:

The NFS server does no write caching.  Every write operation will block until the data has hit the platters, confirmed.  That's a physical disk head motion per system call.

The reason?  Because an NFS server can crash and reboot, with the client not being aware of it.  In this scenario, you don't want to lose writes, ever.

Modern NFS server appliances actually DO write caching... to battery-backed RAM.  If they crash and reboot, then they first flush out the battery-backed cache to the platters, then check/repair the filesystems, and then continue.  A power failure does not mean the loss of your data.

Experiment: try your application while Z: is mapped to a Network Appliance file server in CIFS mode.  Does it still suck?
David Jones Send private email
Friday, August 26, 2005
 
 
I wouldn't expect CIFS to do local write caching.  If the performance you're seeing isn't adequate you probably just need better hardware.

Check out the documentation for the CreateFile (particularly FILE_FLAG_WRITE_THROUGH) and FlushFileBuffers Win32 functions for ways to manage write buffering to the local disk.  There are probably others.
Doug Send private email
Friday, August 26, 2005
 
 
No amount of better hardware is going to make a difference when WriteFile() changes from buffered local 50usec to network round trip 20msec

Sure, for MY application I can improve performance by simply writing much larger buffers.  But when you have some other application that writes its file 10,000 records, one at a time, it simply never notices that performance sucks because it's writing to a local filesystem.

I'm surprised that Windows doesn't sacrifice this data integrity case for the sake of performance.  Windows CIFS clients are *totally* aware of the CIFS server crashing/restarting.

I guess I expected Windows to be more of a dirty unsafe whore than it really is. :(
Michael B
Friday, August 26, 2005
 
 
Try a samba 3 server (or, if you're adventurous samba 4 - it's still in development). My experience is that Samba significantly outperforms a native Windows server when reading and writing large files.

Another possibility is to use "overlapping IO" (the windows term for asynchronous io) - it won't actually speed anything up for you, but it will stop blocking your process.
Ori Berger
Friday, August 26, 2005
 
 
Instead of using the O/S WriteFile API for writing two bytes at a time, use one of the C or C++ run-time-library functions which implement client-side buffering on top of WriteFile.
Christopher Wells Send private email
Saturday, August 27, 2005
 
 
Write your own buffering filter driver.
Its not easy, but if it matters that much to you.

Or run locally, and write your own network file synchronizing filter.

IE create a filter that replicates all activity on local fileX onto remote fileY.
B
Monday, August 29, 2005
 
 
"I'm surprised that Windows doesn't sacrifice this data integrity case for the sake of performance.  Windows CIFS clients are *totally* aware of the CIFS server crashing/restarting.

I guess I expected Windows to be more of a dirty unsafe whore than it really is. :("

Wanna know why?  Think back to 95, 98 etc.  Windows was locking up so much and needing the power cord pulled that no one would be able to make it through a week without rebuilding if the file systems was flaky.  Chop the power to Linux, Unix and Windows.  Typically Windows will pop right back up without any maintenance required the other two will be hit and miss.
Crackhead
Monday, September 05, 2005
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz