Blobfuse Limitations | Differences from POSIX

Following are unsupported in blobfuse

multiple nodes writing to a single blob If you have applications that try to write to the same file simultaneously, mounted on different nodes, the last writer will win. Your previous writes will be lost.

chmod, chown: For non-adls storage accounts blob storage does not support permissions and ACLs per object. Because of this, blobfuse does not support chown and chmod.

When mounted with default options, all files will get 770 permissions, and only be accessible by the user mounting with blobfuse.

If you desire to allow anyone on your machine to access the blobfuse mount, mount it with option -o allow_other

readdir count of hardlinks: For performance reasons, blobfuse does not correctly report the hardlinks inside a directory. Hard links for empty directories are returned as 2. Hard links for non-empty directories are always returned 3 regardless of the actual hard links.

non-atomic renames Atomic rename operations are not supported by the Azure Storage Blob Service. Single file renames are actually two operations - a copy, followed by a delete of the original. Directory renames recursively enumerate all files in the directory, and renames each.

special files Blobfuse supports only directory, regular file and symbolic links. Special files such as device files, pipes, sockets are not supported.

Following behaves differently from filesystems

Data is persisted to Blob storage only after a file handle is closed When a write happens on a file, the data is first persisted into the cache disk space, however is not persisted to Blob storage. Only after a file handle is closed (e.g. you close the file), the file is uploaded to Blob storage. If there is an issue with the upload to Blob storage, you will be notified through an error returned to the Close call so you can determine whether the data was persisted or not.