Re: reiser4 plugins

[David Masover <ninja@slaphack.com>]

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

Hans Reiser wrote:
> Nikita, I respectfully disagree with what you say about the state of our
> atomicity code.   It is not so far away as you describe, and probably 6
> man weeks work could polish it off.  You don't see the value in what I
> define as useful, namely atomicity without isolation.  Since you don't
> see that, it is harder for you to see that something is close to working
> and just needs 6 weeks of someone who groks what I am asking for.

How about a poor-man's isolation -- any process other than that
responsible for the transaction sees a consistent state, never a
transaction-in-progress.  I'm sure there's a name for that.

So, until the transaction commits, all apps can still see the original
state, except the one actually writing the transaction.  After it's
done, all apps see the new consistent state.

Isolation can then be done easily in userspace, via voluntary locking.
If the isolation needs to be global, the user can take a performance hit
and do mandatory locking.  Either way, locking and unlocking could be
seen as part of the transaction.

Details follow, most of them pure speculation on my part...

I'm not sure how this ties into the bigger kind of transaction, as
you've decided to let userspace handle the rollback in the large,
multi-file transactions, but for a single file, it seems obvious (famous
last words).  You've got the wandering stuff, meaning that the new file
(or changes to a file) are written to a new space on disk, after which
you update the metadata (blocklist?) -- presumably atomically.

So, it already seems inherent in the system, but it should be defined.
For some transactions, it doesn't make sense to do this, especially huge
ones (where storing changes separately may well fill up the disk) which
make more sense to have an application handle the rollback.

Here's a bad example of such a situation:  We're doing a brand-new
install, and we start by unpacking a tarball from the installation
media.  After the tarball is unpacked, we start installing packages.
But, if the installation fails, maybe we want to roll back to the
initial tarball, change some installation parameters, and try again.  In
such a situation, it makes more sense to just unpack the tarball again
than to try to roll back each change individually.

This is a bad example because you shouldn't have to start over from the
beginning, and even if you did, exit codes should be enough for this
kind of installer.

Anyway, I'm not sure quite how this works when dealing with more than
one file, but we already have atomic metadata operations, and here we
have an example of a somewhat atomic file operation, so I'm sure the two
can be stringed together... somehow...  Conceptually, it seems you'd
just be building a COW subtree, and the actual "atomic" part consists of
simply changing the pointer from the original tree to the modified one.
 The cleanup of the original tree need not be atomic.

We do have COW support, don't we?  It was discussed, and we should.

Main point is, I've just described two kinds of transactions:  entirely
FS-managed and userland-rolled-back.  I think they are both useful.
Also, neither looks incredibly hard to implement.  I'm sure I'm wrong
about that, though.

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

iQIVAwUBQru0fHgHNmZLgCUhAQLX9hAAjSO4WkIaqyzeTYyz3l9PW5mWvvUKhxrv
eK3glrQvrEf2HHy8gBfdcqv5RV8BAHfYIh6V/4S9VqmMzpBcUfBfEGRCJg0vcTsj
oVSpzV0/ASdxitMjsHqIz3q3kNRhRuhZoD/ppsVVlH4zZtefioYecyD2asEzTz6w
vAMN08chHR/vQiSDMBPDwkJ5Ov1tyPqdpSA4vBuRreWhDpD32ChBd3epEVXjt090
P0HxddqGR6FXCo9m4z2nTgSFHhAPkrOJE5bNS72hpk94nTfLRMI1DDTKw7J4AO10
U2mdjaXD5AUyahwE3diMcsxrH+94orE5bmK4yvgLUquBZ+OeRFoH0u8FG7sD3coP
2YkJewbhSrCQD69hrrR3pluwds3aoe+awj3x2WOk+6NV9xajw0czPs1P3cEw2Dwt
Fl2+92M6545UUbysL51Dvk+DWp/PRniAL1nBoZ1q9nBlhYIiL7ccr48sXP2PxoZw
nSQ1BDASCZalS6AFlMhI6A6U/OxIMzEZQr/cq1J9/dwRdrST2VLqiQdaCmsfgmL5
EVxA1C0tFjOPWwAlzVHB7MisxDp491w6WrxzV3r8x9vCwJZ747+2RNF3z2ah0A56
bVV6ZTjOK/pAsC0p+cfZS3NOTtvmP8x9QXQFll9WZvVEgFMYaOYkPlL6qwtpdNNR
r0yOvDy1TLI=
=FeCh
-----END PGP SIGNATURE-----