[lkml]   [2001]   [May]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Why side-effects on open(2) are evil. (was Re: [RFD w/info-PATCH]device arguments from lookup)
On Friday 25 May 2001 00:00, Hans Reiser wrote:
> Daniel Phillips wrote:
> > I suppose I'm just reiterating the obvious, but we should
> > eventually have a generic filesystem transaction API at the VFS
> > level, once we have enough data points to know what the One True
> > API should be.
> Daniel, implementing transactions is not a trivial thing as you
> probably know. It requires that you resolve such issues as, what
> happens if the user forgets to close the transaction, issues of
> lock/transaction duration, of transaction batching, of levels of
> isolation, of concurrent transactions modifying global fs metadata
> and some but not all of those concurrent transactions receiving a
> rollback, and of permissions relating to keeping transactions open.
> I would encourage you to participate in the reiser4 design discussion
> we will be having over the next 6 months, and give us your opinions.
> Josh will be leading that design effort for the ReiserFS team.

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

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?

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:53    [W:0.085 / U:2.712 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site