Graciously accepted. Coming up with something sensible in a mere 6
months would be a minor miracle. ;-)
- what happens if the user forgets to close the transaction?
I plan to set a checkpoint there (because the transaction got
too big) and log the fact that it's open.
- issues of lock/transaction duration
Once again relying on checkpoints, when the transaction gets
uncomfortably big for cache, set a checkpoint. I haven't thought
about locks
- transaction batching
1) Explicit transaction batch close 2) Cache gets past a certain
fullness. In both cases, no new transactions are allowed to start
and as soon as all current ones are closed we close the batch.
- of levels of isolation
- concurrent transactions modifying global fs metadata
and some but not all of those concurrent transactions receiving a
rollback
First I was going to write 'huh?' here, then I realized you're
talking about real database ops, not just filesystem ops. I had
in mind something more modest: transactions are 'mv', 'read/write'
(if the 'atomic read/write' is set), other filesystem operations I've
forgotten, and anything the user puts between open_xact and
close_xact. You are raising the ante a little ;-)
In my case (Tux2) I could do an efficient rollback to the beginning
of the batch (phase), then I would have had to have kept an
in-memory log of the transactions for selective replay. With a
journal log you can obviously do the same thing, but perhaps more
efficiently if your journal design supports undo/redo.
The above is a pure flight of fancy, we won't be seeing anything
so fancy as an API across filesystems.
- permissions relating to keeping transactions open.
We can see this one in the light of a simple filesystem
transaction: what happens if we are in the middle of a mv and
someone changes the permissions? Go with the starting or
ending permissions?
Well, the database side of this is really interesting, but to get
something generic across filesystems, the scope pretty well has to be
limited to journal-type transactions, don't you think?
-- Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/