Hi,
On Wed, Feb 28, 2001 at 11:08:22PM +0100, Andreas Gruenbacher wrote:
>
> 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.
Right. And you will pretty-much _always_ have such windows. Imagine
moving a file between filesystems: unless you can create the file and
copy over all ACLs and EA in one atomic operation, you'll always see
inconsistencies during the process.
> > 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:
Right, but *why*? Is it actually needed? If it doesn't solve the
entire atomic-updates-over-tons-of-attributes problem, then is it
really worth implementing a half-solution?
VMS doesn't have it, and I never saw any complaints about it. It
_did_ have a way of locking metadata, so that apps could build their
own compound operations.
> 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.
Locking also fails to guarantee consistency on-disk, because you end
up not specifying to the OS the entire set of updates to be committed,
so things break after a crash.
All of these mechanisms have flaws, so I'd vote just to allow
applications to use flock() to synchronise themselves voluntarily, and
not complicate the API with it.
Cheers,
Stephen
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
