That is because almost all applications use filesystem calls (directly or indirectly), but only some apps may need a transactional API. Consider a process P1 u

That is because almost all applications use filesystem calls (directly or indirectly), but only some apps may need a transactional API. Consider a process P1 using a fictional transactional API in an OS and is accessing the path `/a/b/c` and is creating some files under directory `c`. Consider another process P2 executing a `mv /a/b /x`. P1 uses the transaction API, but P2 is not. So, under the covers the system calls will all have to use the new transactional API to ensure global correctness. That is asking a lot of the kernel and possibly makes a lot of legacy programs slower. The other question to answer is: do we want ACID properties or eventual consistency to be guaranteed by the transaction? What to do when some processes want ACID guarantees and some processes are okay with eventual consistency? How does the kernel handle concurrent running of these processes in contention with the same resources under two different transaction semantics. These are some of the reasons why the transaction management is better handled in userspace.