Re: The argument for fs assistance in handling archives

[Hans Reiser]

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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/