[Samba] Improving Samba write performance on Linux

[Björn Jacke]

On 2010-12-08 at 11:41 -0800 Jeremy Allison sent off:
> How do I get the patch ?
> ------------------------

some additional info on this: for Samba 3.5.x setting "strict allocate
= yes" is already doing that fast preallocation for file allocations
done via the SET_FILE_INFO call - if filesystem, kernel and libc
support that.

For 3.5 Jeremy's patch adds the feature that preallocation is also
being done for the mentioned 1-byte writes, which is being done by
some applications.


> Note that this must be run on a file system that supports extents,
> with a kernel modern enough to support the posix_fallocate() call
> working directly on the underlying file system (2.6.23 or later), and
> a glibc that supports it (glibc 2.7 should be modern enough). Also
> note that "strict allocate = yes" *must* be set on the exported share.

The 3.5 smb.conf man page contains some useful hints about which
(file)systems support fast preallocation and which don't:

  strict allocate (S)

     This is a boolean that controls the handling of disk space
  allocation in the server. When this is set to yes the server will
  change from UNIX behaviour of not committing real disk storage blocks
  when a file is extended to the Windows behaviour of actually forcing
  the disk system to allocate real storage blocks when a file is created
  or extended to be a given size. In UNIX terminology this means that
  Samba will stop creating sparse files. This can be slow on some
  systems. When you work with large files like >100MB or so you may even
  run into problems with clients running into timeouts.
  
     When you have an extent based filesystem it´s likely that we can
  make use of unwritten extents which allows Samba to allocate even
  large amounts of space very fast and you will not see any timeout
  problems caused by strict allocate.  With strict allocate in use you
  will also get much better out of quota messages in case you use
  quotas. Another advantage of activating this setting is that it will
  help to reduce file fragmentation.
  
     To give you an idea on which filesystems this setting might
  currently be a good option for you: XFS, ext4, btrfs, ocfs2 on Linux
  and JFS2 on AIX support unwritten extents. On Filesystems that do not
  support it, preallocation is probably an expensive operation where you
  will see reduced performance and risk to let clients run into timeouts
  when creating large files. Examples are ext3, ZFS, HFS+ and most
  others, so be aware if you activate this setting on those filesystems.

   Default: strict allocate = no


> 
> As Linux is our primary deployment platform and most Linux
> distributions are now using ext4, I'm proposing to change the default
> of the "strict allocate" smb.conf parameter to change from "no" to
> "yes" for the 3.6.0 release.

this would result in timeouts and performance penalties for the
majority of existing systems out there when large files are being
written.

Jeremy: would you like to have a look at bug 6942 ? That one is about
this topic in the AIO case, which is still not handled ...

Cheers
Björn
-- 
SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen
phone: +49-551-370000-0, fax: +49-551-370000-9
AG Göttingen, HRB 2816, GF: Dr. Johannes Loxen