I have experimented with Azure File Service as a form of network file system that can be mounted by several VMs simultaneously -- something that regular Azure virtual hard disks are not capable of. An Azure VHD can only be attached to a single VM at a time.

However, when mounting an Azure File share via the SMB protocol, I observe some really poor write performance.

The set up is as follows, I've started a Canonical:UbuntuServer:16.04-LTS:latest VM on a Standard_DS2 VM.

When the boot process completes I follow the official instructions to mount the Azure File Share via SMB.

sudo apt-get install cifs-utils
sudo mkdir -p /mnt/azure
sudo mount -t cifs //<storageaccount>.file.core.windows.net/<file-share-name> /mnt/azure/ -o vers=3.0,username=<storageaccount>,password=<base64-encoded>,dir_mode=0777,file_mode=0777,serverino

Then I run this simple write performance test:

time for i in $(seq 1 500); do echo "hello!" > /mnt/azure/hello.txt; done

real    0m20.673s
user    0m0.032s
sys     0m0.124s

As can be seen, it takes over 20 seconds to complete. As a comparison, running the same test on my local machine (with SSD drive), I see the following numbers:

time for i in $(seq 1 500); do echo "hello!" > hello.txt; done

real    0m0.031s
user    0m0.004s
sys     0m0.024s

That is is completes in about 30 milli seconds. So there is almost a performance penalty factor of 1000 when running against the Azure File Share.

Are such performance numbers to be expected or am I missing something?

2 Answers 2



Bear in mind that although the local disk and Azure Files are fundamentally network storages, the later uses an I/O API instead of direct hardware access. The latency will be a lot higher. Said that let's try a simple math:

You are making 500 requests and each time it opens and closes a connection:

500 requests / 20.673.sec = 24.18 Req/sec

24.18 / 1000 = 0,02418s to complete each request, which is great.

If you need performance against small and/or a large number of files, then Azure File Storage is not for your use case. In theory, it can achieve 1000 IOPS and 60MB/sec.

Additionally, let's face it, SMB/CIFS is very slow dealing with small files.

  • So I guess that makes Azure Files a poor fit for my use case - (mostly) reading and writing of many small files.
    – hal
    Mar 13, 2017 at 5:33

I'm not sure this is the entirety of the problem, as that does seem like a big difference, but bear in mind:

  1. Azure File Storage is standard storage, not premium, so it's all spinning disk, no SSD, it will always be slower than your SSD.
  2. Your running across the network now, that adds some time as well. Different size VM's have different limits, a D2 is going to be limited to about 1.5Gb/s
  • note that latency is mostly more important than bandwidth in this situation. Mar 11, 2017 at 10:29
  • @DennisNolte Very true
    – Sam Cogan
    Mar 11, 2017 at 11:02
  • I know is an old thread, however:In Azure the VM size is irrelevant when working with Azure Files Share mounted via SMBv2.x or SMBv3.x . What is relevant is the limit on the Azure Files Share itself, which is 1000 IOPS and 60mbps (soft limit here.. in certain conditions can go up to 90 mbps).
    – Marin N.
    Sep 18, 2017 at 9:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.