Linus Torvalds wrote:
>On Wed, 1 Sep 2004, David Masover wrote:
>
>
>>And that is the right solution. Not the only one, but the right one.
>>Caching isn't the only thing sorely in need of transaction support right
>>now. Actually, I find it hard to think of anything on Linux which
>>shouldn't have transactions -- why should /etc/fstab or
>>/home/david/homework be more fragile than /var/lib/mysql?
>>
>>
>
>It's easy to talk big.
>
>It's damn hard to _implement_ a complex system, and make it stable and
>bug-free, and support legacy applications.
>
>There is a reason why we do only what _must_ be done in kernel space.
>
> Linus
>
>
>
>
Filesystems need transactions. Given that they need it, it was very
tempting to build an infrastructure offering some of the functionality
to user space, and so we did in reiser4. What we have is very
rudimentary, but I think I am prepared to say that important aspects of
high performance transactions are better done in the kernel than in user
space. It will be interesting to see what aspects of transaction
functionality belong in user space as our transactions API comes into
existence. Clearly there are some things about isolation that are better
implemented by user space because user space can make optimizations the
kernel doesn't know enough to make. Still, it will be interesting to see
how low we can make the overhead of isolation. Right now reiser4
supports atomicity but not isolation, which is to say we offer to
guarantee that a set of operations will either all survive a crash or
none of them will, but we don't let you roll them back without a crash.
(Originally I called this a transcrash rather than atomicity, but nobody
liked the term.) Being modest in our ambition was important to
performance, but maybe in time we will find a high performance way to be
more ambitious.