bored

im to bored to code
going to watch anime & troll you fags instead

Wait, there's more! I'm getting more and more interested on this project as I think of the awesome things I could implement. First of all, I'm going to use MySQL's InnoDB engine from a C FUSE driver. It has the replication and transactional features I'd want to have. I also considered SQLite, but its transactional/locking capabilities for this kind of thing would fail. And there's more! How about...?

- Transparent block compression (as in NTFS), enabled or disabled per file or per directory.

- Sparse files. Sparse files would not even consume index rows; if you create a file with 4 KB of data after 50 GB of unwritten blocks, you consume about 5 KB of disk space.

- Small files optimization: Files smaller than 256..3072 (TBD) bytes require no blocks.

- Optional logging to allow point-in-time recovery of your filesystem. Watch out for the performance and space hit, but it's still an optional feature you might want to have, that comes for free with the database.

- Support for multiple devices joined up to form a single filesystem: if you have two 80 GB hard disks, you can have a 160 GB volume.

- Multiple isolation levels to choose from: read uncommitted (disable tx isolation), read committed, repeatable read, serializable.

- An option to flush to disk on commit (for ACID compliance), or every second. Various levels of caching. All of this is a matter of DB configuration.

- A simple way to use and benefit from transactions from anywhere, even shell scripts.

- Of course, I'd support files larger than 4 GB, and directories with more than 4 GB of files (you'd have to be insane to create them though). Maybe I go for 4 GB blocks per file (and blocks are going to be 1 KB to 16 KB, TBD, probably customizable on FS creation).

- The ability to create mountable backups is gone (would need two MySQL instances due to InnoDB using a single tablespace, not going to do that), but I can provide some sort of tar utility that supports my metadata instead.

- Filesystems stored as regular files within other host filesystems will not need to be fixed-size; they'll be able to autoextend, taking as much space as necessary at peak.

- I'd provide ls, stat and other utilities supporting my metadata, copy on write and other features with the forced indentation of code, as either functions to use in your own indentation-forced programs, or shell utilities.

- Though I wouldn't be going to support full-text search from the start, I may leave extra flags to support it in the future, even with plugins to search within ODF document contents and such. (Though there already are many good full-text search utilities that will work with this filesystem transparently, too.)