>>12
| - Arbitrary metadata
I do like this idea. But it is slightly irritating that FS designers think of this as a FS problem rather than an OS or VFS problem. So every other FS has a different, incompatible implementation of metadata storage. A software developer wishing to use the metadata must decide on a particular FS to support (or waste time accomodating multiple FS's). But, it isn't cool to come up with an improvement for VFS, not as cool as having your own FS named after you.
| - Fast listing of files given any metadata
I like that, though. Metadata is nearly worthless if you can't search it with a fast index. That's what b-trees are for, afterall.
| - Copy on write.
Doesn't ZFS have that?
| - 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
Sounds messy. There's a reason why filesystems ensure metadata consistency only and forget data consistency (besides ordering, that is). If two applications start a transaction on the same (set of) files concurrently, what happens when they both commit? Does one transaction get to replace the other? Or does each application get to act on the uncommitted data of the other? You'd still end up with an indeterminate state at the end, either way.
Data's consistency is a problem for application developers to figure out. The FS just keeps metadata from taking a shit.
| - Creation date (NOT metadata change), data modify date, metadata modify date and access date optional to keep track of.
Where are you going to get the extra info? Does the VFS provide the separate "metadata modify" and "data modify" timestamps for you 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.
I don't know what the database is needed for. Why is your FS even concerning itself with where it is located? That's a problem for the OS to deal with. The FS just works on the blocks that the OS gives to it, wherever they come from does not matter. Have you ever used loopback devices?
| - Ability to connect to remote databases,
Ok, now I am convinced you're not just talking about making a FS.
>>18
| - Transparent block compression
Yes please.
| - Small files optimization:
You mean like tail files? Sure, as long as you can guarantee that in case of a failure: Stale data or data belonging to other files won't become exposed to users, and a failed write won't ruin the blocks of the other tail files (wouldn't want to put files in unnecessary risk of corruption).
You've got an enormous amount of work ahead of you.