[HOW] Veracrypt file container very slow write on SMB

[EriChan]

Samba does not read back the data to compare or verify it after writing.The ~20x speed drop is not caused by extra network or read traffic, but by physical disk latency and IOPS limits when synchronous flushes are enforced.

Here is what actually happens under the hood:

• Client Flush Requests: Backup applications and OS file managers frequently issue SMB2_FLUSH commands, explicitly asking the NAS to commit data to physical non-volatile storage before sending the next chunk.

• Hardware Blocking (fsync): With strict sync = yes, Samba strictly honors these commands by calling Linux fsync(), forcing the hard drive to write data immediately to physical platters/NAND.

• The IOPS Bottleneck: Physical hard drives (and USB-connected storage) can only process around 100 to 200 physical write/flush operations per second (IOPS). If a client sends frequent flush requests with small buffers, the mechanical seek latency forces throughput down to around 4 MB/s ($100 flushes/sec x small buffer).

When strict sync = no is set, Samba intercepts these flush requests in high-speed system RAM (Page Cache), completely bypassing physical disk latency during transfer—allowing the NAS to easily sustain 70 MB/s+.

[Gremlin]

Thanks for the explanation. I was wondering which end did what
I appreciate these short "inside the NAS" explanations when they are available.

[wenuam]

Then if the NAS can sustain 70 MB/s write speed with no data loss (I checked) what is the "strict sync = yes" waiting for if the data can be written fast enough to the disk ?

Is "Linux fsync()" the bottleneck ? I don't think this alone could send the writing speed to a crawl, otherwise there is a big design flaw there.

Write speed fluctuate nonetheless even with "strict sync = no", but not as much and at least the general throughput is comfortable.