> - No (at all powerful) notion of transactions. Mutation without transactions is extraordinarily primitive. There is nothing that prevents you from implementi

> - No (at all powerful) notion of transactions. Mutation without transactions is extraordinarily primitive. There is nothing that prevents you from implementing these in userland. Does not belong in the kernel, since the kernel can't know what are your atoms that must be atomically committed. Research how databases do it. > - No multiple FS roots to indicate boundary across which data will never be synchronized. (This is also good for how to spread data across multiple devices, a low-level concern.) You can check what device a file belong to with stat(2). It's the st_dev member. You can also check it from the shell with the stat command. > - Overall pushes people to maintain their own structure within files rather than use FS's trees. And that's entirely ok. Hierarchies are not for databases. Database-y problems are not the problems that the POSIX fs solves. > - Block size, locality out of control. I actually heard that Unix filesystems have traditionally been quite good at preserving locality. That's why I don't know of any defrag tool for e.g. ext3. Overall, if the FS does not solve your problems, implement your own abstraction. That's perfectly ok.