If you experience difficulty backing up with Acronis, you may need to go to the “Strict Allocate” feature under Windows networking (Advanced, Global options) and type in “No”.    Save the settings to change.  Version 2.15b of the software Changed Windows networking default settings to set strict-allocate to ‘no’ to fix backup failures using Acronis backup.  This setting may be “yes” on other versions of the software so should be checked if you’re using Acronis or have backup failures with any other software.

 

If you’d like more explanation on this setting, which is intended to increase Linux Samba performance here is an excerpt from the Samba performance documentation:

When a Windows client application sends a request to write one byte at position 500MB on a newly opened (empty) file, the SMB/SMB2 client redirector has to ensure that 500MB+1 bytes are really allocated on the target system. However, sending a simple SMBwriteX/SMB2_WRITE request with an offset of 500MB could easily cause a client timeout. An assumption built into the SMB/SMB2 protocol is that the target file system behaves like a Windows server, so the NTFS driver on the server would have to allocate 500MB worth of file system blocks in order to complete this request, which may take longer than the 30 seconds usually allowed for an SMB request.

What the Windows client redirector does in this case is to send a sequence of 1 byte requests, to cover the extension needed on the open file. In the reply to an NTCreateX/SMB2_CREATE call, the SMB server returns a value called the “allocation size”, which is equivalent to the file system block size on a UNIX/Linux style file system. The “allocation size” is more flexible than the underlying file system block size, as (at least for Samba) it can be specified on a per-share basis.

This allocation size is used by the client redirector to specify the space between each 1 byte write call used to pre-allocate the empty space when a file is being extended. For example, if the allocation size is set to 1MB (the default in Samba) then when extending a file by 500MB the client redirector will issue 500 intermediate 1-byte SMBwriteX/SMB2_WRITE requests before issuing the real write request (at 500MB+1 byte) to complete the application write request.

Each of these one byte writes is unlikely to time out, thus allowing SMB/SMB2 to deal with writes that extend a file to an arbitrary size (within the limits of the file system and the protocol) without having to worry about network time outs.

Making writes efficient on Linux  By default, when Samba receives these 1 byte “extension” write requests, it simply does a normal one-byte “sparse” write at the required position in the file. This is very fast, but only causes one file system block (the block “dirtied” by the one byte write) to be allocated. When the real data is finally written into the file, the blocks then have to be allocated for real on the file system. Because these blocks are not then allocated “in order” on the file system, as it were, these actual writes can be quite slow.

The most efficient way to allocate file system blocks when data is to be written into all of the file (for example, a streaming video write) is to allocate what is called an “extent” on the file system. The requested blocks are then laid out by the underlying file system (ext4 or XFS) in a very efficient way which causes the actual writes to be much faster than having to allocate them dynamically.

How does a Linux application (Samba) get access to this new extent-based allocation call ? Simple, it’s built into glibc on modern Linux distributions via the posix_fallocate() call. In the new patch that has gone into Samba 3.5.7 (and also all future versions of Samba), when the smb.conf parameter:

“strict allocate = yes”

is set on a share, whenever a file is extended by an SMBwriteX/SMB2_WRITE call, call Samba calls posix_fallocate() to ensure the file extends to at least the size given as the offset in the SMBwriteX/SMB2_WRITE request, then does the actual write. In tests done on an ext4 file system, changing to “strict allocate = yes” and using the posix_fallocate() call in this way increased the write performance of Samba by 2/3 on a NETGEAR ReadyNAS box as tested by the Intel NASPT test tool, available here: http://software.intel.com/en-us/articles/intel-nas-performance-toolkit/

The specific tests used to measure the performance increase were the “File Copy to NAS” and the “HD Video Record” tests.