Blobfuse: Azure Blob Storage as a filesystem, with a deadline attached

A filesystem that speaks the blob REST API

Blobfuse is described as a Microsoft supported Azure Storage FUSE driver, and the About section explains the mechanism in one sentence. It is an open source project that provides a virtual filesystem backed by Azure Storage, using the libfuse open source library, the version 3 line, to communicate with the Linux FUSE kernel module, and implementing the filesystem operations using the Azure Storage REST APIs.

So the shape of it is clear. The kernel sees a normal filesystem mount, the driver translates those operations into REST calls, and there is no virtual machine and no disk image in between. That is the difference from the many other ways of using object storage as a filesystem, and it is why the driver is a Go program with an Azure SDK dependency rather than a network protocol implementation of its own.

The readme lists the workloads it is aimed at, and they are consistent with each other: artificial intelligence and machine learning training and checkpointing, high performance computing simulations, Kubernetes stateful workloads, big data analytics and preprocessing, and large scale backup and archiving. In each case the pattern is the same, data that lives in blob storage and is read repeatedly by Linux software that expects a path.

The feature list adds the details that matter in practice. Standard file operations with caching, health monitoring, blob filtering, and the ability to preload containers or folders into the local cache for faster access. That last one matters for training jobs, where the alternative is reading the same shards from the network for every epoch.

The project is developed in Go, the module path carries a version 2 suffix, and the last push was on 2026-10-22, so the work is current.

Caching or streaming, and that decision drives everything else

BlobFuse supports two operating modes, and the readme points you at a Microsoft article to help you decide which one suits your workload.

The caching mode works by caching data locally on the virtual machine nodes, and it is described as ideal for repeatedly accessed data that fits on the local storage of the node. The streaming mode reads large files in chunks directly from storage, and it is the one aimed at big artificial intelligence and machine learning, genomics and high performance computing workloads.

The distinction is not a preference, it is a cost model. A cached mount turns a network service into local disk after the first read, which is the right behaviour for a dataset that gets scanned many times. A streaming mount keeps the storage in charge and pays the latency on every pass, which is the right behaviour for a file larger than the local disk or for a job that reads it once.

The configuration files shipped in the repository match those modes. There is a block cache configuration, a file cache configuration, and a file cache configuration that includes a shared access signature.

Two smaller features sit alongside. Blob filtering narrows what the mount exposes, which matters on shared storage accounts where not every container should be visible to a job. And preloading a container or a folder into the local cache is the explicit version of the caching behaviour, for the case where you know in advance what the job is going to read.

Version 1 support ends in September 2026

There is a note in the readme that should be the first thing you read if you are planning a deployment, because it sets a deadline rather than a preference.

BlobFuse v2 is the latest version and has many significant improvements over BlobFuse v1. Support for BlobFuse v1 ends in September 2026. The readme tells you to migrate to version 2 using the provided instructions, and there is a MIGRATION.md file in the repository root for exactly that.

This is the kind of deprecation that a virtual filesystem project has to do and that a lot of projects do badly, but here it is stated in the opening section, a month and change before the cut-off in the current timeline. The release list supports the reading that version 2 is where the work is going, with 2.5.4 in July, 2.5.5 in August and a 2.5.6 preview in September, all tagged with the binary name prefix.

The licensing note is also worth noting, because the repository listing records a custom licence while the readme says the project is licensed under MIT. For a driver that most people will install as a package rather than read, that discrepancy matters less than it would for a library, but it is the kind of thing to check before you vendor it.

The project is a Microsoft supported one, with the code of conduct, the security policy and the technical steering group document all present in the tree.

Mounting, logging and monitoring are three separate topics

The readme is organised around the operations rather than around the code, and the three operational topics are worth taking separately.

Mounting a container uses the mount command. You can either include the configuration settings you want as command line parameters, or provide a configuration file that contains your settings, and the readme points at the installation documentation for the details. The example configuration files in the repository, the block cache, the file cache and the file cache with a shared access signature, are the templates for that file.

Logging has a specific default that is easy to miss. By default BlobFuse logs warnings to the system log. You can route the logs to a local directory, change which types of information appear in them, or disable logging entirely, by changing the default configuration.

Monitoring is a separate tool, called the health monitor, used to monitor mount activities and resource usage. The documentation describes what data you can obtain from it, how to enable it, and how to view the output reports.

The help is conventional and worth knowing about, because the command set is not small. To see the list of commands you type the binary with the help flag and press enter, and to learn about a specific command you include the command name with the same flag, for example the mount subcommand with the help flag.

blobfuse2 -h

blobfuse2 mount -h

The readme also points at a known issues and limitations page and a troubleshooting page, which is where to look before assuming a behaviour is a bug.

What the dependency list says about the engineering

The module file is a good map of how the driver is built, and a few entries stand out.

The Azure SDK for Go appears in four pieces, the core package, the identity package for authentication, the blob package and the data lake package, which is the multi-protocol path for hierarchical namespaces. Those are the only real dependencies that matter conceptually; everything else is infrastructure.

Two of the more unusual entries come from a Microsoft engineer's own repositories, one for blob filtering and one for a cache with a least recently used eviction policy. So the filtering feature and the eviction policy of the local cache are separate components with their own release cycles, which is sensible for the parts most likely to need to change independently of the driver.

The rest is a well known Go stack. A daemon library for running in the background, the Cobra and pflag pair for the command line, Viper for configuration, a file system watcher and the fsnotify library for reacting to changes, a Prometheus process filesystem library for the metrics that the health monitor reports, the testing library, and an ini parser.

The build and release machinery is visible in the repository root as well. There are pipeline templates and four workflow definitions, one for the main continuous integration, one for code coverage, one nightly and one for releases. There is a shell script for building, another for installing Go, and two more for keeping the repository compliant, one fixing copyright headers and one fixing the notices file, which is the kind of housekeeping that large vendors automate and small projects do not.

There is also a test directory, a test data directory, a performance testing directory and a development container, which is a reasonable amount of scaffolding for a driver that has to work across distributions and kernel versions.

Contributing to this project means signing Microsoft's agreement

The contributing section is short and it is a good illustration of what contributing to a large vendor project involves.

Most contributions require you to agree to a Contributor License Agreement, a document declaring that you have the right to, and actually do, grant the rights to use your contribution. The readme points at the Microsoft CLA site, and explains the mechanics: when you submit a pull request, a bot automatically determines whether you need to provide the agreement and decorates the pull request accordingly, with a label or a comment. And the detail that matters most in practice is that you only need to do it once across all the repositories that use that agreement.

That is the difference between a company open source programme and an individual hobby project, and it is not necessarily a downside. A contributor license agreement is a legal promise about ownership of the contribution, and the bot approach means nobody has to be asked to sign anything by hand.

The project has also adopted the Microsoft Open Source Code of Conduct, with a link to its frequently asked questions and a direct email address for questions about it.

The readme closes with the two requests that are usual for a project of this kind: issues, feature requests and questions go to the repository's issue tracker, and the detailed documentation lives on Microsoft's learning site rather than in the repository, with the repository holding the migration guide, the change log, the security policy, the technical steering group document and the notice file.

The overall impression is of a productised open source project: a supported driver with a scheduled end of life for the old version, a compliance pipeline, an on-call style monitoring tool and documentation that assumes a reader who has a storage account and a mount point in mind.

Editorial conclusion

Adopt BlobFuse if a Linux workload has to treat Azure Blob Storage as a mounted filesystem, particularly for training data, checkpointing or high performance computing, because the driver hides the REST API behind ordinary file operations. Do not adopt it if your workload needs random writes or POSIX semantics the blob API cannot give, since the readme points to a known issues page rather than claiming full filesystem behaviour. Before you deploy, decide between caching and streaming, because that choice changes the configuration and the cost profile, and note that version 1 support ends in September 2026, so a new deployment should be on version 2 from the start.

Frequently asked questions

Official sources

1. Azure/azure-storage-fuse on GitHub
2. Issues
3. README
4. Releases