bored

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

I can't create new threads so I'll hijack this one.
This thread is now about filesystems.

Suppose you crated a filesystem using FUSE and a database as a proof of concept of some sort. Which features would you like to have?

I'm aiming at (for real, I'm already designing it):

- The basic features (Unix metadata, links, symlinks, shared and exclusive locking)

- Inverse list of files to hard links, so for a given file you can know which other files link to it as well (e.g. ln car cdr; Now you ask: which is my other car? My other car is a cdr).

- Arbitrary metadata for files, based on dictionaries. You can take any file and assign it a key and a value for that key. Keys are unique per file. You should be able to retrieve all key, value pairs, which files have certain keys, and which files have certain keys with certain values as fast as possible. Keys are strings, values can be strings or ints.

- Fast listing of files given any metadata (static or dynamic), so you could obtain, say, a list of files created after a certain day, named like lol*interweb and with metadata "type=image" in logarithmic time. An SQL console would be available too, of course.

- Copy on write. There should be a copy operation that copies a file by just copying the block indexes marked "copy on write". The file takes almost no space and no time when copying, and new blocks are copied upon modification. This would have the advantages of hard links and copying files for some purposes.

- Transactions, ACID compliant. You should be able to start a per-process transaction and operate with files in a way isolated from other processes, then commit the changes (which would be effective all at once) or rollback them (undoing absolutely everything you may have done). Nested transactions too; you can begin, do A, begin, do B, rollback, commit, and A would get done, but not B.

- Snapshots. You should be able to open a snapshot to obtain a consistent picture of the filesystem, without locking concurrent writing operations.

- Creation date (NOT metadata change), data modify date, metadata modify date and access date optional to keep track of.

- The filesystem's data location depends on the database. I'd want to support both filesystems in a regular file (inside a host filesystem, which one doesn't matter at all) and raw devices.

- Backup/archiving system that should produce a file which you can later mount as is, keeping metadata and everything. I.e. once you archive, you can either unarchive or just mount the result to read and modify it.

- Ability to connect to remote databases, thus becoming a network filesystem, only with all these features, including locking and transactions (which would kick NFS's ass).

- Asynchronous replication to any number of remote filesystems (mounted as read-only). Multi-level replication possible too. I would have to think about multi-master replication, but I'd love to include that feature too.

- Repair utility: first the database repairs its own tablespace, then a higher-level utility checks that indexes and metadata are ok or fixes them.

Well, what do you think? Of course this wouldn't be fast, and it's not intended to be your boot filesystem or for /lib or /usr, or anything of the sort. It's a filesystem with rich features for storing your own data, like pictures. So if ReiserFS is your car, this would be your cdr.