{"slug": "fiberfs-1-0-is-released", "title": "FiberFS 1.0 Is Released", "summary": "Reza Naghibi released FiberFS 1.0 on November 9th 2026, a high-performance distributed POSIX filesystem built on S3 storage that stores content as actual files rather than blocks, so what appears on the filesystem matches what appears in S3 buckets. FiberFS is designed to combine the S3 storage ecosystem with CDNs to address S3's high latency and limited API, and existing S3 files can be imported into FiberFS as is, with newly written files and directories placed into S3 alongside them. Naghibi said the file-based approach limits POSIX compatibility options to \"limited to nonexistent\" compared with the block route, which can piggyback on existing filesystems and libraries.", "body_md": "Reza Naghibi - November 9th 2026\n\nFiberFS 1.0 is now available. FiberFS is a high performance distributed POSIX filesystem built on S3 storage. So to mark this occasion, I would like to talk a bit about how FiberFS was conceived and why it’s designed the way it is.\n\nFirst, why create FiberFS? I guess I’ve been lucky enough to work on a number of interesting fields in software. Things like search, CDNs, big data, and machine learning, just to name a few. One constant has always been the importance of data. This is a bit obvious, but what isn’t obvious are the complexities around storing, managing, and scaling storage infrastructure. A big piece of this data storage puzzle has always been S3. S3 has emerged as the de facto storage service of our time and it does a few things really well: it’s simple, it scales, it’s vast, it’s durable, and it has an ecosystem of vendors offering competing products and services. What’s not so great is that the S3 API is quite limited and S3 services are usually remote and can have high latency. But there is already a solution to the latency problem, CDNs (ie: giant internet caches). Their sole existence is to make things on the internet faster and appear much closer than they really are. So what if we combined this S3 ecosystem with the CDN ecosystem in a nice and easy to use way? This is the motivation behind FiberFS.\n\nSo what’s the best way to combine S3 with CDNs? The answer I came up with was a filesystem. A filesystem is by definition a piece of software which manages data. So by definition, a filesystem fits perfectly here. However, typical filesystems don’t work well with things like HTTP, the internet, and S3. So rather than try and force everything together until it works, it’s better to just start from scratch and design FiberFS as a new kind of filesystem, one designed around a different set of constraints and principles.\n\nWhen it comes to filesystems, blocks are the standard. What is a block? It’s just a blob of data. Usually it’s a uniform size, that makes it easier to manage and store. A lot of times disks are called block stores because they pretty much only deal with blocks. These days, blocks can be stored anywhere. So can we just store generic filesystem blocks on S3? Of course, this has been done many times before and a lot of successful S3 filesystems have taken this approach. However, there is one problem with this approach and it’s that it goes against how people want to use S3. People use S3 to store files and they expect to see individual files sitting in their S3 buckets. So while there is nothing inherently wrong with storing blocks on S3, it does feel a bit unnatural.\n\n  For FiberFS, we went down the route of what S3 expects. Content is stored as actual files. What you see on your filesystem is what you see on S3 and vice versa. If you have files currently sitting in S3, those files can be imported into FiberFS as is. Newly written files and directories will be placed into S3 side by side with the existing files. When you are done writing a file using FiberFS, your file will just be sitting there in S3, just as you expect. (Please see our [technical overview](https://fiberfs.io/content/fiberfs_technical_overview) for more information on how [FiberFS stores itself on S3](https://fiberfs.io/content/fiberfs_technical_overview#how-does-fiberfs-store-its-files-on-s3).)\n  \n\nPOSIX compatibility is where things get tricky for S3 filesystems. Just as a refresher, POSIX compatibility means that you can arbitrarily list, read, write, seek, append, delete, and do all kinds of standard filesystem operations on your data. If you choose the S3 block route, then you can just piggy back on the existing ecosystem of filesystems and libraries and get POSIX compatibility that way. If you choose the file route, then your options are limited to nonexistent. S3 has API limitations on how it can write, further complicating the POSIX compatibility picture. So a lot of times you are forced to choose a subset of POSIX you can support, and it’s up to the users not to cross those unsupported boundaries, which is less than ideal.\n\n  So the path for FiberFS is 100% distributed POSIX support. The good news is that we are almost there, you can view our [POSIX compatibility table here](https://fiberfs.io/content/fiberfs_technical_overview#fiberfs-posix-support). Just as an exercise, I went ahead and did a full git checkout of the FiberFS repo directly on a FiberFS S3 mount. I then did a fully parallelized compile and then a fully parallelized test run. Everything worked as expected. Not only that, performance was on par with my local EXT4 filesystem. Note that this test was done using FiberFS’s internal S3 harness running on the same local EXT4 disk, so S3 round trip times were well under 1ms. If your S3 round trips are 100ms, then you can expect the test to take much longer, so be warned. That being said, this is still a great start for FiberFS because there are many latency and performance optimizations in the pipeline. It’s also important that FiberFS starts from a position of consistency and then moves towards performance optimizations and not the other way around.\n  \n\nMetadata is another very important part of a filesystem. Metadata allows a filesystem to organize itself into the files, directories, and other POSIX features that you have come to expect. Filesystem metadata is a workhorse, it needs to accept a stream of operations which constantly alters its state. Filesystems solve this by embedding what amounts to a database into its storage blocks. S3 does offer the ability to store metadata along with its files, but using it at filesystem scale is painfully slow, it's one S3 round trip per file. Specialized APIs also exist for this purpose, but they are non-standard and can lock you into a particular service. It’s for this reason a lot of S3 and distributed filesystems use an actual database for their metadata. This allows filesystems to operate at much faster speeds than what their block storage could achieve natively. But it also restricts the filesystem to clients which have access to the database. Typically distributed filesystems are not exposed over the internet and are normally sealed off into tightly controlled networks.\n\nFiberFS breaks this pattern by not using a database at all. It stores its metadata as compressed JSON directly on S3. This JSON is aggressively cached and FiberFS can operate on this JSON faster than a round trip database query in most cases. Because FiberFS is powered completely by S3, your filesystem can be shared across networks, sites, across continents, and even made public on the internet. And because there is no database, FiberFS rids itself of a huge source of operational complexity. This also allows FiberFS to use only four basic S3 operations: HEAD, GET, PUT, and DELETE, allowing it to work across a very wide spectrum of S3 services.\n\nCaching is probably one of the most important parts of FiberFS. FiberFS caches all content, including metadata. As mentioned before, CDNs are purpose built for S3 style workloads, and FiberFS takes full advantage of this. FiberFS also provides three more layers of caching on top of CDN caching: page cache, disk cache, and clustered cache. Page cache provides instant access to frequently used files and directories. Disk cache is a persistent cache which saves S3 files and metadata locally, allowing for long term local access. And clustered cache allows multiple hosts to combine their disk caches together resulting in scaled out storage and performance.\n\nAI is definitely something that needs to be discussed given how it's transforming the software industry. FiberFS is human designed and human coded and it will remain this way for the foreseeable future. AI is absolutely leveraged, but in a support capacity only. We do feel this gives FiberFS a strategic advantage over AI coded projects since FiberFS has access to the same AI capabilities, but with the added bonus that humans are firmly in the loop and fully understand the design and codebase. This is not meant to be a controversial take or a jab at AI coded projects, it’s simply a choice the FiberFS project has made.\n\nFiberFS has a fully open sourced license with a single condition. If you are running more than 32 hosts, we ask for a $2 per host fee. This fee amounts to a tiny fraction of what it costs to run 32+ hosts, so we do feel it’s fair and a relative bargain. If you have less than 32 hosts, which should be the case for most people, FiberFS is completely free to use. In all cases, FiberFS has no feature paywall and allows forking, private modifications, and even commercial usage. Our target users are people who just want an easy and convenient way to connect S3 to their servers and computers. And our goal is that we can earn just a bit of money to keep the lights on. If there is a way to make FiberFS more free, please let us know your ideas.\n\n  Obviously give FiberFS a try. You can read more about it [here in our technical overview](https://fiberfs.io/content/fiberfs_technical_overview) and our [installation guide is here](https://fiberfs.io/content/building_and_running_fiberfs). Project wise, there is still a lot of work to do. We have plans on adding more POSIX support and also making FiberFS faster and more efficient for everyday workloads. We also plan on adding support for OS X and we have some really cool features in the pipeline like transaction histories and rollback support.", "url": "https://wpnews.pro/news/fiberfs-1-0-is-released", "canonical_source": "https://fiberfs.io/blog/fiberfs_1.0_is_released", "published_at": "2026-11-10 20:37:38+00:00", "updated_at": "2026-11-10 20:54:21.313359+00:00", "lang": "en", "topics": ["ai-infrastructure", "developer-tools"], "entities": ["FiberFS", "Reza Naghibi", "S3", "POSIX", "CDN"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/fiberfs-1-0-is-released", "markdown": "https://wpnews.pro/news/fiberfs-1-0-is-released.md", "text": "https://wpnews.pro/news/fiberfs-1-0-is-released.txt", "jsonld": "https://wpnews.pro/news/fiberfs-1-0-is-released.jsonld"}}