4 ms·
Perhaps inode numbers should never have been numbers in the first place. If they were strings it would be trivial to prepend a volume ID.
by aaron_m04 5y ago
Perhaps inode numbers should never have been numbers in the first place. If they were strings it would be trivial to prepend a volume ID.
- st_goliath 5y agoThe original research Unix systems had a filesystem that resolved filenames to inode numbers (which were basically indices into a lookup table of inode structures). Kinda sorta like DNS where you piece-by-piece resolve a hierarchically structured string into a number that you can use to directly address a target, until you reach the last one. If two paths resolve to the same inode number, and thus to the same inode and data, that's called a hard link. The whole concept of inodes and inode numbers is deeply ingrained into the Unix userspace API and Unix filesystem semantics. The whole purpose of inode numbers is to not deal with strings. What you are suggesting is essentially a fundamental redesign of Unix filesystem semantics that requires each file to have at least two paths: a hierarchical, user generated one, and a non-hierarchical, auto generated one.
- turminal 5y agoThat would create a whole lot of other problems and probably some performance penalty, because strings are much, much more difficult to work with in the context of a kernel filesystem driver.