Re: reiser4 plugins

[David Masover <ninja@slaphack.com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Nikita Danilov wrote:
> David Masover writes:
> 
> [...]
> 
>  > 
>  > What we want is to have programs that can write small changes to one
>  > file or to many files, lump all those changes into a transaction, and
>  > have the transaction either succeed or fail.
> 
> No existing file system guarantees such behavior. Even atomicity of
> single system call is not guaranteed.

No _existing_ filesystem.  But I seem to recall that this was one of the
design decisions of Reiser4, and that the system call itself was pushed
off to 4.1?

Maybe I'm just wrong about how big a transaction can be.  Maybe it was
limited to a single file.  I don't think so, though.  From the
whitepaper:  "Stuffing a transaction into a single file just because you
need the transaction to be atomic is hardly what one would call flexible
semantics."

I also seem to recall that the rolling back of the transaction, should
it fail, was supposed to be handled by the application.  This doesn't
quite click with the whitepaper, but it could work.

More whitepaper goodness:

"A new system call sys_reiser4() will be implemented to support
applications that don't have to be fooled into thinking that they are
using POSIX. Through this entry point a richer set of semantics will
access the same files that are also accessible using POSIX calls.
Reiser4() will not implement more than hierarchical names. A full set
theoretic naming system as described on our future vision page will not
be implemented before Reiser6() is implemented (Reiser5 is our
distributed filesystem, Reiser6 is our enhanced semantics, whether we
implement Reiser5 or Reiser6 first depends on which sponsors we find ;-)
). Reiser4() will implement all features necessary to access ACLs as
files/directories rather than as something neither file nor directory.
These include opening and closing transactions, performing a sequence of
I/Os in one system call, and accessing files without use of file
descriptors (necessary for efficient small I/O). Reiser4 will use a
syntax suitable for evolving into Reiser5() syntax with its set
theoretic naming."

So, some sort of transaction is planned.

But, as I said, I wasn't paying enough attention.  Maybe there is a
technical reason why this can't be done in Linux?

>  > > it doesn't stop the system dead in its tracks waiting for some very long
>  > > transaction to finish?
>  > 
>  > We've also discussed this.  For one thing, if we can have transactions
>  > in databases which don't stop the database dead in its tracks, why can't
>  > we do it with filesystems?
> 
> Because to have such transactions databases pay huge price in both
> resource consumption and available concurrency (isolation, commit-time
> locks, etc.), and yet mechanism they use to deal with stuck transactions
> (which is simply to abort it) is not very suitable for the file system.

Oh, really?  If we've got application support through sys_reiser4?  The
application should be ready to deal with a transaction abort.

I'm still not convinced of any of that paragraph.  I don't know enough
to argue the point, but it intuitively feels wrong.  After all, if the
metadata is atomic, and we are allowed to make our own system calls, why
can't we make the data atomic?

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iQIVAwUBQrrGOngHNmZLgCUhAQJZhw//dmJ6S2GlGT6J5YI9DTCyoTDIPUYNb8o0
M1me6KDTElzzQ3yUak/eUd0sbGBAQcf0vn/iVscfq2DoAwnUWxHjht+PaOA98axR
0pnofqE291QLTQJ36epW0kKqFjavVVsrpD80llcaCFz9Rq48W40DoI5CWuX1RQqK
pCnr9vYe8cAsRY+PzV9/KUaSQ+eZJ9daLsAmMwA3Gcxo4XYqILlZm90X3QQTdc8W
gnKSabG3zIjEozfgG/nvtV/09mktHINGq3ud8W1XubBOXs4z+ECsLyvi7QNW83Bq
b/wTDUX3PkrjDHnfcmFkFZJqRrCBD9Ko36f9NThxuaba5eV7kb6h+qx+kS5ZM6Lm
bh90TjJrIpJ4aQr2qrPRAE85GSnvSlyi3E01gk/+UnkBFMoTqTvw2dPb0GhvMINM
EhSUhEyeaopWXIdv3IszOOpbHJLwczixLDBtZ8OFDS26bnJGj7YlnTjdf+TZ9CGf
ZXn7GaG16CiSTOt0YkKk2UGZz+AOubPAUHc6v8Wg587qXWKD3cXVQeZVqYwJG/8B
G5qq51LB6jypjAoP4uSeuTs4DfANGi2H2mHjZVAyaGcwzhxf3ffGRFkfjElAj8RA
RdmB6bq10nt32mL7YP8+n7xa38iCP+ks9wsoOY2KBBDlOpHu07xb/c2DS9yfTCpj
FvMShQw6EBI=
=S7ds
-----END PGP SIGNATURE-----