4

What is the correct option for Samba's "strict allocate" when serving a zfs volume?

The documentation says:

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 option is really designed for file systems that support fast allocation of large numbers of blocks such as extent-based file systems. On file systems that don't support extents (most notably ext3) this can make Samba slower. When you work with large files over

100MB on file systems without extents 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

So, if I have strict allocate = yes, Samba will not do pre-allocation, which is has no performance advantage on ZFS?

7
  • Have you tested both settings to see if there's a performance advantage either way? Apr 8, 2017 at 12:22
  • I noticed no appreciable change, but I may not be testing the correct workloads, or my computer may otherwise be misconfigured.
    – Mikhail
    Apr 10, 2017 at 3:38
  • Well, if your system is fast enough, I'd recommend that you don't overthink it. There's no need to fix things that aren't a problem, even if they could be better. Apr 10, 2017 at 9:57
  • Not fast enough because it can't saturate the 10G.
    – Mikhail
    Apr 10, 2017 at 10:05
  • Not fast enough because it can't saturate the 10G Not many things can. Saturating a 10G network is hard to do even in short bursts. What kind of disks are you trying to write to? Most SATA drives are going to have difficulty sustaining 50 MB/sec transfer rates under normal filesystem-type workloads. You can get more than that, but the entire system has to be engineered to do so. Apr 10, 2017 at 10:09

1 Answer 1

1

With strict allocate = yes, Samba will pre-allocate space. Since ZFS doesn't have extent-based allocation, the manpage says this is slower than strict_allocate = no.

You might think that if you tell the fs to allocate the entire space for your huge file in advance, there is a higher chance of that space being contiguous than if you allocate it piece by piece; however, I'm not sure this would be the case with zfs, which strives to make all data writes sequential. It certainly won't be the case if you have compression enabled, because the preallocated space will be empty and will compress to a single block, so you gain nothing by enabling strict_allocate.

FWIW, I tried to use fallocate -x to create a 10GB file on a compressed ZFS instance and it took 2 minutes, which is probably too long for a CIFS client. strace output shows that the allocation is done using several million pwrite64() calls. The actual fallocate() call is not supported:

fallocate(3, 0, 0, 10000000000) = -1 EOPNOTSUPP (Operation not supported)

This is with a fairly recent zfsonlinux git master.

Based on the above I'd say it would be useless and highly disruptive to enable strict_allocate on a compressed filesystem; for uncompressed ones with dedup disabled, it's probably only highly disruptive but not necessarily useless.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .