From mboxrd@z Thu Jan  1 00:00:00 1970
Date: Thu, 26 Feb 1998 17:01:40 -0600
From: G. David Butler gdb@dbSystems.com
Subject: [9fans] create(2)/open(2) race for file creation
Topicbox-Message-UUID: 72eeafa0-eac8-11e9-9e20-41e7f4b1d025
Message-ID: <19980226230140.4X_lVK6qugh3MOI_cKsHi7AZ2iDvAgHTXbD8CO--lLs@z>

>gdb wrote:
>> 
>> I'm sure many of you wish this topic would go away, but...
>
>I actually think it's quite interesting :)  
>
>Admittedly I do not know the entire scope of the problem, but 
>it seems to me that the effect that is desired is to use the fs 
>as a centralized database, with update collisions being resolved
>at the os-layer.

No, I want them resolved at the fs; as they are.  I only want
the os-layer to make the fs resolution visible.

>                  This seems to me to be a challenging problem
>for the fs/os, particularly since the fs/os as seen by applications
>may have mounts and binds going across the network to a variety
>of locations.

Even open(2) does NOT have the same behavior across arbitrary
bind(2) structures.  That is NOT my expectation.  I DO expect
open(2) and create(2) to have the same behavior on directories
that have the same bind(2) structure.

I did notice an interesting response on this thread in comp.os.plan9
that didn't make it to the list about a property of union directories.
It went something like "the behavior of a properly implemented
union directory should not differ from the behavior of a flat
directory with the same contents".  That would be a hard trick to
pull off since the constitutient directories would have to be
incorporated in the union in the same order, always, no matter
who, no matter when, no matter from where.  For that to happen
in Plan9, the union directory would need to be constructed using
an RPC between the fileservers [fileserver in the generic sense, not
the physical machine called a fileserver].  The mount would be allowed
only after it was constructed.  It also means the directory should not
be available if any of the constitutient fileservers is unavailable.
After implementing this trick, the bind(2) system call would be
unnecessary and A-Bad-ThingTM.

Anybody want to take that on as a research project?

>Might it be appropriate to use a multithreaded server process
>to handle the transactions, and have the clients attach to

[snip]

This idea has been suggested many times during this discussion.
In Plan9 this both unnecessary and overly complicated.  The 9P
protocol is sufficient to express the ideas completely and the
fileservers as implemented support 9P properly.  The only thing
that corrupts the design is the implementation of one system call.

Just Fix It.

David Butler
gdb@dbSystems.com