This isn't a network file system -- it's ReiserFS4, which brings its
own hatred but attempts to bring things around towards sanity.
That's OK, it's hateful in non-network file systems as well.
It's just that network file systems seem to have concentrated the
hateful aspects much more effectively than even things like HFS+.
The attempt is to provide filesystem transactions using a new
interface.
begin() read(), write(), ... commit()/rollback()?
Some of the kernel people seem to want an API to be developed which
could
be used across all filesystems, whether they implement transactions or
not, while the Reiser folks wants to wait before designing a
standardized
interface for something that isn't complete yet in their own codebase,
let alone usable with other filesystems.
I vote for an API that can be implemented on all file systems, but not
necessarily efficiently.
The problem is that it reserves a fixed percentage of filesystem size.
I
believe it's 5%. This means that with a 250 GB volume, 12.5 GB will be
reserved *just in case* a transaction which requires that much space
hits the pipe.
So? Many existing file systems require a bigger reserve than that.
Though it seems more logical, if the API supports transactions, to
simply force a rollback() on the application. If the application is
using transactions then it has to be able to handle that in any case.
