Bug 8352 - Random data file corruption from Samba debug log output
Random data file corruption from Samba debug log output
Product: Samba 3.3
Classification: Unclassified
Component: VFS Modules
All Linux
: P5 major
: ---
Assigned To: Samba Bugzilla Account
Samba QA Contact
Depends on:
  Show dependency treegraph
Reported: 2011-08-04 15:51 UTC by bgilman
Modified: 2011-08-09 15:37 UTC (History)
0 users

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description bgilman 2011-08-04 15:51:31 UTC
We have been experiencing a problem with intermittent file corruption that began around late 2010, when I increased the amount of debug logging in our VFS plugin.

The problem manifests itself in one of two ways:
1. Samba debug log information is written to an output file stream at the same time that content is being written.
2. One of the things that we do in our VFS plugin is manage our own audit log for important file operations.  Occasionally, the corruption problem will manifest itself by periodically redirecting audit log output in front of a file being written to the samba share.

This occurs on the two production installations we have.  Here is the relevant version information -
Samba 3.3.4-1
(Primary) Kernel - 2.6.18-128.1.6.el5    Distro- RHEL5
(Secondary) Kernel - 2.6.9-42.0.8.ELsmp     Distro- RHEL4

Our data files are actually sitting on a NetApp file share that is mounted from Linux.

There is mention of this problem in "The official Samba-3 HOWTO and reference guide" by John H. Terpstra, Jelmer R. Vernooij - Section 13.6; third bullet point.  Here's a link -

Please let me know if there is anything you would like to know from me in aiding your investigation.
Comment 1 Volker Lendecke 2011-08-06 17:17:01 UTC
I do remember this bug, I just can't say exactly what it was. I'm pretty certain it is fixed in recent releases. Please re-open if you can reproduce with 3.5.11.


Comment 2 bgilman 2011-08-09 15:37:25 UTC
Hi Volker,

Thanks for your feedback.  Good to hear that this has been fixed.  

The problem is happening only in our production environment, so we likely won't be allowed to move to 3.5.11 any time soon.  I'll take a look through past change logs, but is there anything else you can remember about when this was solved, or any small detail about what the fix involved?