Nasuni’s Object File System Puzzles Me

Nasuni sells enterprise file storage as a service using a global file-system and caching devices at the edge for performance.

You could be forgiven for thinking that Nasuni is an object storage company, given how much time they spend talking about object storage. Their presentation at #TFD25 seemed to constantly reference object storage, but without clearly linking it to customer benefits. It also wasn’t clear why the choice of object storage was important, as compared to other options.

Talking about how great your stuff is because it’s built with object storage feels too much like saying how great Brawndo is because it’s got electrolytes. So? Why should I care?

Given what I know about how filesystems are constructed, let’s see if we can figure out why Nasuni’s use of object storage matters.

All filesystems are a kind of database. There is data (stored in chunks of bytes on some sort of media, often read-write but sometimes read-only) and there is an index to the data so you can find all the chunks that are associated with a given file (or block of data). You can call this a key-value store if you like, where the index is the key and the value is the data.

There’s often layers of index->data because the index itself is made up of data that needs to live somewhere. The filesystem is basically a way of making the structure of this data make sense. Is that set of bytes a folder name, or a list of where to find the list of files that make up the folder’s contents?

This is a vastly oversimplified version of how things work, but it shows that there’s nothing to stop you using a set of objects in an object store as your raw material for creating a filesystem. One object might say “I am a filesystem, here is where to find the bits of me”. Then the logic of your filesystem code can interpret the set of key-values and figure out how to retrieve all the objects that contain the data that makes up your image or video file or database table.

Nasuni’s UniFS filesystem is a continuous versioning filesystem. It seems that Nasuni uses objects as its fundamental storage pieces and only creates new ones when things change. This sets up an append-only structure, so you can always go and find the pieces that made up your earlier filesystem provided you keep track of where they all are.

Nasuni can do this because it treats an object store as a functionally infinite amount of storage. Instead of a finite set of flash or disk sitting in an array somewhere, cloud-based object stores are an abstraction over the physical infrastructure. The physical infrastructure is still finite, but if you keep adding more of it fast enough, the abstraction provides the illusion of an infinite amount of storage.

This abstraction means Nasuni can pretend that there is no limit to how many writes they can do, because the object store never fills up. It’s not actually true, but it’s true enough. Not only can Nasuni just keep writing new data forever, it can also write new indexes forever, so you can always go find what the filesystems looked like at a previous point in time.

That’s why Nasuni says you can have unlimited snapshots, and that they’re immutable, and why you can do very granular restores, and why rapid recovery happens. I was able to figure this out, but it wasn’t obvious from Nasuni’s presentation, which was a shame.

The main reason for my difficulty was that Nasuni spent a lot of time saying how great they were in broad, generic terms and that object storage was the magic that made it possible, but didn’t clearly connect the choice of object storage with how they provide the benefits to customers. That’s what I’ve tried to do here. While I’m hopeful that my educated guesses are likely to be accurate, I’m not sure and it would have been better if Nasuni has just explained this clearly in the first place.

I see this a lot with technical companies. Moving between different levels of abstraction and maintaining the connecting thread is hard to do well, but it’s really important if you want to talk about your underlying technology. Nebulous benefits untethered from concrete reality are too vague and untrustworthy, but technical details disconnected from the higher-level goals of customers are arcane and confusing. Finding the right balance requires good judgement as well as skill and experience.

Nasuni seems like a really solid option despite the fumbles of this presentation, so I’m not writing them off by any means. I’m just busy, and I don’t really want to have to work this hard to understand a vendor’s products. Making it easy for customers to understand why they should care about you makes everyone’s lives easier, so it’s worth investing in.