3 ms·
You say that like the file system is the ground truth to how we use a disk. It is nothing but another abstraction we've invented to manage blocks on some persis
by smasher164 5y ago
You say that like the file system is the ground truth to how we use a disk. It is nothing but another abstraction we've invented to manage blocks on some persistent medium. The vast majority of people wouldn't notice if you replaced their FAT partition with a key-value store, where the keys were paths delimited by slashes (with some UX to traverse paths).
- theamk 5y agoAre 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 agoThe 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 agoAll 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)
- snek_case 5y agoFiles seem like a pretty natural abstraction: a blob of data, an array of bytes that forms a self-contained unit. There's something that seems natural about that. You can attach all kinds of meta-data to files, but then you run into the issue of which types of tags people care about or are supported by different OSes, etc. The idea of hierarchically separating files, and giving them names, and also types in the form of the extension, seems like a pretty good system to me. In terms of tagging files, I feel like, with good machine learning, that can be done automatically. No human effort required. You could just search all your files with a vague natural language description of what you're looking for. Kind of like tagging webpages... Does a good search engine even care about your tags?