[Samba] Improving Samba write performance on Linux
bj at SerNet.DE
Thu Dec 9 06:58:27 MST 2010
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
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
> 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
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 ...
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
More information about the samba-technical