I want to make a filesystem for funos. I like the existing directory tree structure of filesystems, so I'll keep that. The fs will live on an SD card or an eMMC, so I don't have to worry about seek time like I would if it were living on a spinning disk (note to self: check that assumption sometime). I'm pretty sure the seeks are going to be fast, especially because of wear-leveling algorithms which don't even place the blocks (physically) in order on the drive.
I've heard enough about the unreliability of storage media that I want some form of error detection and correction to be included in the fs. I could put that at a lower layer, but then you just write the code somewhere else. It would probably be more complex that way. Plus, I don't want to have to trust the correctness of some lower layer.
I want any valid utf-8 character to be available for the filename. I hate that filesystems vary in which characters they allow in filenames. (FAT32, I'm looking at you!) Symlinks are cool, but they're a pain in the butt to implement because then every single program has to worry about "follow" semantics. I don't want to have to think about that. I'm not sure about inodes. It's basically the simplest way to describe the location of a file. I don't want to deal with hard links though. So if I do include inodes, I'll limit them to one directory entry per inode.
I have a file sync program called syncd that I'd like to implement on top of this fs. It needs to know which files have been modified, renamed, or deleted since the last sync. On Linux, I keep a snapshot of the state of the filesystem (file hashes and modified times) at the time of the last sync, and then compare that snapshot to reality on the next sync. This is slow. I'd rather have a log with that info. So I'll make a log of it--at least for files that are descendants of "watched" directories.
File locking is tricky. Ideally, one application would be able to open a file at a time, and any other application wanting to access that file would be blocked. But what should an application do while it's blocked? Make the user wait? I don't like waiting. So I'll probably just resolve write conflicts at the application level. If the application accesses a file that has been modified by someone else since it opened the file, it will receive some notification. If it's a music program, it could just reload the song and continue playing it at the same position. If it's a text editor, it could open the new file and show a diff to the user. That all seems okay, and it probably won't happen very often.
My biggest problem is interoperability. I either have to:
I feel that I must expose the phone as a block device, but maybe that could just be for transferring files, and not for putting them in the filesystem. If I want to transfer from the phone to the computer, I could choose which directory to expose as FAT32, and that's all the computer would see. Not a bad option. I'll probably go with some custom version of #2.
Sounds fun!