People who know me (as a GlusterFS developer) probably expect another "not a real file system" rant here, but this actually looks pretty cool. I'd rather see someone combine existing technologies like this to serve a particular need, rather than reinvent all sorts of wheels themselves.
I saw that, but I'm still a bit confused. Is it saying that if you have two volumes using this system then one will be a copy of the other? Or some data will be on one volume and some will be on the other, but both volumes will look like they have all the data?
A classic filesystem associate each path with a content.
A content-addressable filesystem associate each path to the hash of its content, and then keeps a separate mapping of each hash to a content. Which means that if two files are identical (= have the same hash), then the content is only stored once.
A union filesystem is a filesystem that is organised as a set of "layers". You have a normal filesystem at the bottom, above it you have a set of layers, where each layer only stores the files that have changed (each time you create a snapshot, the filesystem creates a new layer).
In practical terms, you have a filesystem where taking snapshots and reverting to older snapshots is very efficient.
Or, in other words, a filesystem that behaves like a git repository.
Without looking at the code, I assume each file is stored as a binary blob with a hash, snapshot and volume id. This would allow you to keep identical files only once.
The last paragraph is conjecture. However the idea is that the filesystem is arranged so that it only stores the difference(or a different version) of the file.
Which doesn't sound like either content addressable or a union filesystem. Unless it's using the filenames as indexes in which case I guess it is content addressable, but has a serious flaw in that you're limited to only one unique filename:content pair per filesystem.
