<?xml version="1.0" encoding="UTF-8"?>
<!-- Generated on Wed, 25 Nov 2009 12:16:14 -0800 -->
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <atom:link href="http://software.intel.com/en-us/articles/windows-client-cifs-behavior-can-slow-linux-nas-performance/feed/" rel="self" type="application/rss+xml" />
    <title>Intel Software Network Comments feed</title>
    <link>http://software.intel.com/en-us/articles/windows-client-cifs-behavior-can-slow-linux-nas-performance/feed/</link>
    <description></description>
    <language>en-us</language>
    <item>
      <title>By Laurent Xhardez</title>
      <description><![CDATA[ 
Very usefull.
Indeed the only paper I found talking about this big issue.
However, in my case, the strict allocate = yes option in samba fixed the poor write performance of unknown file size generation.

Thanks again Mason
 ]]></description>
      <link>http://software.intel.com/en-us/articles/windows-client-cifs-behavior-can-slow-linux-nas-performance/#comment-13</link>
      <pubDate>Thu, 21 Jun 2007 01:31:17 -0700</pubDate>
      <guid isPermaLink="true">http://software.intel.com/en-us/articles/windows-client-cifs-behavior-can-slow-linux-nas-performance/#comment-13</guid>
    </item>
    <item>
      <title>By Volker Lendecke</title>
      <description><![CDATA[ Would it be possible to get network traces of the runs? The way the Samba Team deals with these performance problems is that we create load files for our smbtorture utility that enables us to replay the exact same test very easily. From network traces we can generate these load files and play with different server options easily. I would be delighted if you could contact the Samba Development community at samba-technical at samba.org.

Thanks,

Volker Lendecke

Samba Team ]]></description>
      <link>http://software.intel.com/en-us/articles/windows-client-cifs-behavior-can-slow-linux-nas-performance/#comment-9585</link>
      <pubDate>Thu, 11 Dec 2008 02:15:56 -0800</pubDate>
      <guid isPermaLink="true">http://software.intel.com/en-us/articles/windows-client-cifs-behavior-can-slow-linux-nas-performance/#comment-9585</guid>
    </item>
    <item>
      <title>By David Clymer</title>
      <description><![CDATA[ I realize that this is about the effect of client expectations on samba performance, but I&#39;m curious what the comparison would look like for (perhaps?) more common use cases, where the average file size is much smaller than several GB in size. In the organization I work for, our average file size is  ]]></description>
      <link>http://software.intel.com/en-us/articles/windows-client-cifs-behavior-can-slow-linux-nas-performance/#comment-9592</link>
      <pubDate>Thu, 11 Dec 2008 07:55:59 -0800</pubDate>
      <guid isPermaLink="true">http://software.intel.com/en-us/articles/windows-client-cifs-behavior-can-slow-linux-nas-performance/#comment-9592</guid>
    </item>
    <item>
      <title>By David Clymer</title>
      <description><![CDATA[ Our average file size is less than 256kB, which I imagine would greatly reduce the instances where preallocation issues would come into play.

ps. Regarding handling of unwanted characters in article comments: It would be much more friendly to escape or remove unwanted characters from comments rather than just truncating the whole message. :o( ]]></description>
      <link>http://software.intel.com/en-us/articles/windows-client-cifs-behavior-can-slow-linux-nas-performance/#comment-9593</link>
      <pubDate>Thu, 11 Dec 2008 08:00:42 -0800</pubDate>
      <guid isPermaLink="true">http://software.intel.com/en-us/articles/windows-client-cifs-behavior-can-slow-linux-nas-performance/#comment-9593</guid>
    </item>
    <item>
      <title>By Anton Clarke</title>
      <description><![CDATA[ I love it when Linux people blame Windows for poor performance. As a true Unix hacker I just watch the fight.
Here's the sorry truth - the figures presented here are a fudge - the speed of Samba has absolutely nothing to do with Windows expecting the files to be sent to NTFS drives. Set up a Windows Server VM under Linux, load a EXT3 driver so Windows can access an EXT3 formatted drive and watch CIFS fly!Samba was created without any knowledge of how CIFS actually worked - it was all best guess. They did a good job on everything except throughput. Now the CIFS specification is in the public domain it is clear exactly where Samba is losing time - the lag happens not in writing the files but in the exceedingly 'poor' network programming. By poor I mean inefficient. Inefficient because of all the guesswork surrounding CIFS. Because of these 'unknowns' Samba actually spends more time decoding the protocol than actually performing disc transfers. It tries to be 'safe' but leaves us with something that is more of an academic exercise than a viable product. Samba will improve over time, but the question now it should we bother. It's time for something superior to CIFS and the rather fragile NFS to grace our networks ]]></description>
      <link>http://software.intel.com/en-us/articles/windows-client-cifs-behavior-can-slow-linux-nas-performance/#comment-33375</link>
      <pubDate>Tue, 27 Oct 2009 06:18:49 -0700</pubDate>
      <guid isPermaLink="true">http://software.intel.com/en-us/articles/windows-client-cifs-behavior-can-slow-linux-nas-performance/#comment-33375</guid>
    </item>
    <item>
      <title>By Robert Premuz</title>
      <description><![CDATA[ I use MS Windows Backup Utility (ntbackup.exe) to save backup files to a Samba (ver. 3.4.2-1) shared directory that relies on a EXT3 file system. I'd say I experience the issue explained in the article.

If a backup file is large (> cca 10 GB), deleting the file is very slow and causes heavy load on the Samba server (high CPU usage of smbd) which becomes unresponsive during the deletion. If a new backup starts at that time, ntbackup.exe reports the following error (and quits):
"The device reported an error on a request to write data to media."

If the same backup job saves files to a MS Windows shared directory, a large backup file can be deleted much faster.

After adding "strict allocate = yes" in /etc/samba/smb.conf (and restarting Samba) I haven't seen any improvement. ]]></description>
      <link>http://software.intel.com/en-us/articles/windows-client-cifs-behavior-can-slow-linux-nas-performance/#comment-35097</link>
      <pubDate>Fri, 20 Nov 2009 01:29:32 -0800</pubDate>
      <guid isPermaLink="true">http://software.intel.com/en-us/articles/windows-client-cifs-behavior-can-slow-linux-nas-performance/#comment-35097</guid>
    </item>
  </channel></rss>