4 ms·
One of the things filesystems provide is a mapping from paths to data (files, directories, etc). How they provide this varies (tree of path elements, etc), but
by codys 9y ago
One of the things filesystems provide is a mapping from paths to data (files, directories, etc). How they provide this varies (tree of path elements, etc), but saying they don't think about paths (and implying they only think about path elements) is misleading. Nothing prevents a file system from simply putting all it's path to data mappings into a hash table (except the slight difficulty in implementing some common filesystem operations).
- derefr 9y agoMaybe on different OSes, but like I said above, on Linux, many operations will literally just pass a filesystem driver an inode. Your hypothetical driver would need to keep a double-mapping: from inodes to paths, and then from paths to whatever else. At which point, why bother with the second mapping? It's just slowing things down.
- codys 9y agoThe typical (generalized) setup is paths -> inodes (called "refers to data" or ""something"" in my other comments to avoid using the weird terminology we've somehow adapted for naming file system things) and inodes -> actual data on the disk. Whether you actually have that setup on disk is up to the fs format, but regardless of the format it is typically useful (and as you note, generic file system interfaces like the one in linux do require this) to have this extra indirection when tracking things on the software side (ie: not necessarily the storage side, though many file systems do have this type of indirection because it is also useful on the storage side). > Your hypothetical driver would need to keep a double-mapping: from inodes to paths, and then from paths to whatever else. As I've noted in another comment, inodes (`struct inode` in linux) typically contain a lot of information. No additional mapping would be required.
- derefr 9y agoMy point was that paths are part of Linux VFS, and that lookup is already done and invisible when the calls reach the FS driver. So there's no point in implementing an FS driver in terms of paths. It's redundant working-backward from something that was already done for you.
- dom0 9y ago> Maybe on different OSes, Perhaps on a mainframe OS or something that doesn't have a VFS, but all VFS pretty much work the same way conceptually (BSD/nix, Linux, Windows).
- loeg 9y agoThat would make for some very expensive lookup operations on subdirectories (you have to scan the entire hash table) and would entirely preclude hardlinks. So yeah, usually people do not write byzantine filesystems :-).
- codys 9y agoI mean, you could add some indirection & some sort of directory data, if desired to allow hard links & get directory listing perf reasonable. This was mainly an example to show that "paths" in some sense are (or could be) handled by file systems, not an actual design I'd aspire to :)
- loeg 9y agoFair enough. In fact, I think Windows leaves path parsing and component lookup to individual filesystems. (Hence one filesystem per drive letter, and no mount points.)