summaryrefslogtreecommitdiff
path: root/docs/docbook/smbdotconf
diff options
context:
space:
mode:
Diffstat (limited to 'docs/docbook/smbdotconf')
-rw-r--r--docs/docbook/smbdotconf/tuning/strictsync.xml25
1 files changed, 25 insertions, 0 deletions
diff --git a/docs/docbook/smbdotconf/tuning/strictsync.xml b/docs/docbook/smbdotconf/tuning/strictsync.xml
new file mode 100644
index 0000000000..18e778e093
--- /dev/null
+++ b/docs/docbook/smbdotconf/tuning/strictsync.xml
@@ -0,0 +1,25 @@
+<samba:parameter name="strict sync"
+ context="S"
+ xmlns:samba="http://samba.org/common">
+<listitem>
+ <para>Many Windows applications (including the Windows 98 explorer
+ shell) seem to confuse flushing buffer contents to disk with doing
+ a sync to disk. Under UNIX, a sync call forces the process to be
+ suspended until the kernel has ensured that all outstanding data in
+ kernel disk buffers has been safely stored onto stable storage.
+ This is very slow and should only be done rarely. Setting this
+ parameter to <constant>no</constant> (the default) means that
+ <citerefentry><refentrytitle>smbd</refentrytitle>
+ <manvolnum>8</manvolnum></citerefentry> ignores the Windows
+ applications requests for a sync call. There is only a possibility
+ of losing data if the operating system itself that Samba is running
+ on crashes, so there is little danger in this default setting. In
+ addition, this fixes many performance problems that people have
+ reported with the new Windows98 explorer shell file copies.</para>
+
+ <para>See also the <link linkend="SYNCALWAYS"><parameter moreinfo="none">sync
+ always</parameter></link> parameter.</para>
+
+ <para>Default: <command moreinfo="none">strict sync = no</command></para>
+</listitem>
+</samba:parameter>