Bug 2014 - write cache does not honor flush
Summary: write cache does not honor flush
Alias: None
Product: Samba 3.0
Classification: Unclassified
Component: File Services (show other bugs)
Version: 3.0.11
Hardware: All Solaris
: P3 normal
Target Milestone: none
Assignee: Jeremy Allison
QA Contact: Samba QA Contact
Depends on:
Reported: 2004-11-10 15:02 UTC by David Wood
Modified: 2005-05-17 15:15 UTC (History)
0 users

See Also:

Info for Volker (61.26 KB, application/octet-stream)
2005-05-16 08:52 UTC, David Wood
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description David Wood 2004-11-10 15:02:35 UTC
Test script:
use IO::Handle;
$io = new IO::Handle;
open($io, ">Z:/samba_test/blah") or die;
while (1) {
   print $io "blah";
   print "wrote to blah\n";
   sleep 5;
   print "flushing handle\n";
   sleep 5;

If I run the above test script on Windows against a Solaris 3.0.8 smbd *without*
write cache:
* I see nothing before the flush
* I see "blah" immediately after the flush 

The above behavior is what you would expect.  If I run the script on a system
*with* write cache:
* I see nothing before the flush
* I see 4 null characters after the flush:
  useq1.nyc:/u/woodd/tmp/samba_test > cat -v blah; echo ""
* I never see anything other than the 4 null characters 
  until I kill the script.  Once the script is killed the
  filehandle is closed and the file contents are correct.

The write cache is set to 256K:
    write cache size = 262144

Comment 1 David Wood 2005-02-07 09:51:56 UTC
Still a problem in 3.0.11.  David
Comment 2 Gerald (Jerry) Carter (dead mail address) 2005-05-11 05:11:25 UTC
David,  from what I recall, the write cache is managed by smbd and 
not the client.   Jeremy has made changes to the code recently
so I';ll let him decide what to do with this bug.
Comment 3 Volker Lendecke 2005-05-13 00:07:13 UTC
Looking at the code for flushing a file it does indeed flush the write cache if
'strict sync = yes' is set. Do you have that set? If not, I'd be interested in a
sniff and debug level 10 log of smbd while running your script.


Comment 4 David Wood 2005-05-16 08:52:17 UTC
Created attachment 1230 [details]
Info for Volker

Hi Volker,

I've uploaded the information you requested (I also included smb.conf).  The
problem occurs no matter how "strict sync" is set.  David
Comment 5 Volker Lendecke 2005-05-17 05:31:57 UTC
Closing this bug as invalid because this is exactly the behaviour that is to be
expected from setting 'write cache size'. The client requests an oplock on the
newly created file, the flush() from perl triggers another ntcreate&x with
another oplock from the same client. So the client still holds that oplock, and
there is no need to write the data out to disk. The 'flush' does not trigger the
'smbflush' request over the network, so Samba can't do much about it.

Comment 6 David Wood 2005-05-17 15:15:37 UTC
> The 'flush' does not trigger the 'smbflush' request over 
> the network, so Samba can't do much about it.

Okay, thanks for looking into it.  I certainly can't argue the semantics of the
CIFS specification; however, I can say that Samba's behavior has definitely
changed between v2.0.8 and v3.0.X given we used to use the "write cache" option
extensively with no ill effect.

BTW - I've run the same test script against a Netapp filer and it doesn't
exhibit this behavior.  The filer has all cache and oplocks enabled which means
it must be flushing the file after the second oplock request (even without an
'smbflush' request).  It might not be the ideal/correct behavior based on the
CIFS specification; however, it is certainly pragmatic since it avoids problems
like this one.

Thank you again for your time.  David