On Mon, 26 Feb 2001, Stephen C. Tweedie wrote:
> Hi,
>
> On Fri, Feb 23, 2001 at 05:26:24PM -0800, Peter J. Braam wrote:
> > I'd like to cast a vote in favour of test&set.
> >
> > When we manipulate snapshots, these test&set issues will greatly simplify
> > our code: at present we use ioctl's to take locks on things in the kernel.
> > With test&set we need no such hacks.
>
> If you ever need to do a test-and-set over more than one namespace at
> once (eg. setting a DMAPI backup attribute at the same time as setting
> an acl), or need to update multiple files at once, a simple
> compare-and-set-conditionally won't work atomically. You'd still need
> locking.
The problem occurs not only with different namespaces, but with multiple
EA's, no matter in which namespace. However, my (complicated) proposal
allows something like this, so locking is not really needed.
test attribute A
test attribute B
set attribute A
set attribute B
> A set-and-return-old-value operation will let you work on multiple
> files at once. It won't guarantee atomicity but it will let you
> detect and backoff from any collisions. For atomicity, however, you'd
> still need extra locking.
I thought we had dismissed that. The example against
set-and-return-old-value ("saro" below) I gave a while ago was that is
would lead to inconsistencies. Here's another example. Consider reliably
incrementing a counter:
process A process B
--------- ---------
read = 1
read = 1
saro(1+1) = 1 -- fine
read = 2
saro(2+1) = 2 --fine
saro(1+1) = 3 -- oops!
-- critical section!
set(3) -- back off
all processes running in the "critical section" see an inconsistent value
of the counter. Even worse, if process B crashes in the critical section,
the system is left in the inconsistent state permanently.
> So, I'm not sure just how much test-and-set buys us. I'm not against
> it, but I'd like to know why we desperately need it first.
I currently see a number of possibilities to implement reliable updates or
extended attributes:
- test and set, similar to my proposal
- transactions in filesystems
- locking
The first approach uses a sequence of operations that are carried out in
isolation, that is, other processes can't see intermediate results. This
works, but leads to a pretty complex interface.
With transactions I mean a process can acquire something like a
transaction handle on a file, do some changes, and then may try to commit
the transaction, which could succeed or not. That is probably possible to
implement only on journaling file systems.
Locking would seriously mess up the update semantics of extended
attributes (statelessness across EA system calls would be lost), and cause
_huge_ problems for sharing EA's among inodes.
Are there any more ideas? Which solution would you prefer?
--Andreas.
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
