3 ms·

Are you confusing semantics (open, readdir, cwd, ".." etc..) and implementation (directory entries, ".." pointer, etc..)? The blogpost talks about semantic cha

by theamk 5y ago

Are you confusing semantics (open, readdir, cwd, ".." etc..) and implementation (directory entries, ".." pointer, etc..)? The blogpost talks about semantic change -- "open" would mean something else entirely. You seem to be talking about implementation, and yes, users or programs don't care. In fact, many network filesystems like DAVFS and SMB treat filesystem as key-value store, where a single call can get any file by full path. It would be interesting to see an on-disk filesystem that is based on key/value store, but sadly the blogpost's author does not talk about it at all.

smasher164 5y ago
The point I was trying to make was that the directory hierarchy isn't fundamental to how people reason about their data. That you could introduce a little UX over a KV store and those that wanted to mimic the old abstractions could continue to do so. But we could also change the abstractions (like the blog post says) to something like tags, and it wouldn't be any lower or higher level, compared to what we have now.
- theamk 5y ago
  All the "tags" systems I have seen rely on some underlying store -- like in database-based methods, there is main table data (K-V store) and indices (another K-V store); or in symlink-based tags, we use underlying filesystem as data store. So the fundamental filesystem abstraction is K-V store. For efficiency reasons, based on common access pattern, this is often (but not always) implemented as a special kind of a tree. The tags system builds on that and thus is higher level -- even in the Didgets, the main primitive is "open by id", an example of K-V store operations. The whole tags thing is a way to query that store. The hierarchical filesystem also build on that -- but this time the key is (almost) arbitrary string, and the search operator does /-delimited prefix match. There is no real abstraction change when we move from hierarchical files to tags. There is still same old underlying K-V, but we just added an alternative to readdir() (and maybe also forced every file to live in root directory)

by theamk 5y ago

smasher164 5y ago

The point I was trying to make was that the directory hierarchy isn't fundamental to how people reason about their data. That you could introduce a little UX over a KV store and those that wanted to mimic the old abstractions could continue to do so. But we could also change the abstractions (like the blog post says) to something like tags, and it wouldn't be any lower or higher level, compared to what we have now.

theamk 5y ago
All the "tags" systems I have seen rely on some underlying store -- like in database-based methods, there is main table data (K-V store) and indices (another K-V store); or in symlink-based tags, we use underlying filesystem as data store. So the fundamental filesystem abstraction is K-V store. For efficiency reasons, based on common access pattern, this is often (but not always) implemented as a special kind of a tree. The tags system builds on that and thus is higher level -- even in the Didgets, the main primitive is "open by id", an example of K-V store operations. The whole tags thing is a way to query that store. The hierarchical filesystem also build on that -- but this time the key is (almost) arbitrary string, and the search operator does /-delimited prefix match. There is no real abstraction change when we move from hierarchical files to tags. There is still same old underlying K-V, but we just added an alternative to readdir() (and maybe also forced every file to live in root directory)