Hi,
Is there an implied piece of semantics here that with the inode semaphore
taken,
one also has a lock on the EA's of that inode?
[This is not easy to do if the EA is shared, like for ACL's, so let's assume
the EA
is private to the inode.]
- Peter -
-----Original Message-----
From: Stephen C. Tweedie [mailto:[EMAIL PROTECTED]]
Sent: Monday, February 26, 2001 3:13 AM
To: Peter J. Braam
Cc: Andreas Gruenbacher; Stephen C. Tweedie;
[EMAIL PROTECTED]; [EMAIL PROTECTED]; Robert Watson;
Andrew Morgan; Andrew Gildfind; Timothy Shimmin; Theodore Ts'o
Subject: Re: [Acl-Devel] Re: Extended Attributes: Third revised proposal
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.
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.
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.
Cheers,
Stephen
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
