The reason for supporting transactions in the kernel is that there is a
whole slew of security bugs that have their origins in fs semantics
being non-transactional. rename does not cut it as a transactions API.
rename results in horribly performing apps that engage in contortions
that cost a lot of programmer time to code them to stuff a transaction
into a file that can be renamed. Most of the time programmers who
should use a transaction/rename are just too busy to do it, and they
take the risk that the user will lose data and be less secure rather
than write the code to do it right. When they do do it, because it is
complex code, they often screw it up.
That said, there is a whole slew of reasons for not supporting
transactions in the kernel:
* the history of the literature stars transactional filesystems that
paid too high a cost in performance
* isolation is very tricky to do without killing performance
* transactions which are kept open too long are a problem
* avoiding problems with locking shared data structures long enough to
cause painful exclusion of things that should be able to run in parallel
just fine
Reiser4, by being very modest in its ambitions, manages to not pay a
performance cost. We say, isolation and rollback are for user space to
manage until we can find a clever implementation, if such an
implementation can even be found. Even if such an implementation can be
found, there are plenty of cases where special case knowledge of what
the app is doing can improve performance a lot, and thus for that app it
will belong in user space.
All reiser4 does, is allow you to guarantee (using sys_reiser4) that a
limited size set of fs operations will be fused into one atom together,
and therefor will either all survive a crash or none will survive. This
does however meet a lot of apps needs.
Hans
David Masover wrote:
