On Thu, 1 Mar 2001, Stephen C. Tweedie wrote: > 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. You do not have such a window in my proposal, using either test-and-set (or "tests-and-sets") or "verify-and-set". set-and-return-old is simply weaker theoretically. > > > 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? My proposal solves the atomic-updates-over-tons-of-attributes-for-a-single-file problem. That's probably as far as we would reasonably want to go. Still, the *why* question hasn't been sufficiently answered so far. There's the mountainviewdata group with their SnapFS who could use it, but curently they are using an ioctl() workaround which seems to do the job. Then there's the theoretical problem that as long as extended attributes are retrieved/set in a completely stateless manner, locking is not an option. We /could/ instead introduce some sort of locking mechanism, but I'm not sure that's a good design, especially since userspace programs could then block other users' processes. Think of ACLs/Capabilities in EAs, and the issue is becoming serious. > 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. Using flock() to implement some sort of advisory locking probably is an acceptable workaround. I don't see my proposal as flawed in that respect, only as pretty complicated. For me the question is whether we want to live with the complication, or with the limitations. I'm undecided so far. (I'm not favoring the complicated approach because I happened to spend time designing/implementing it. That was just the result of people's requests during our previous discussion.) Cheers, Andreas. ------------------------------------------------------------------------ Andreas Gruenbacher, [EMAIL PROTECTED] Contact information: http://www.bestbits.at/~ag/ - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED]
