From mboxrd@z Thu Jan  1 00:00:00 1970
Date: Thu, 26 Feb 1998 11:33:36 -0800
From: Eric Dorman edorman@Tanya.ucsd.edu
Subject: [9fans] create(2)/open(2) race for file creation
Topicbox-Message-UUID: 72e66d4a-eac8-11e9-9e20-41e7f4b1d025
Message-ID: <19980226193336.UmmltANR93f4ZfjqKLjiFanTNneuhHBhWsVrLUG7K_I@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.  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.

Might it be appropriate to use a multithreaded server process
to handle the transactions, and have the clients attach to
the server process rather than directly to an fs?  This way 
the collisions and race problems can be resolved at the applications 
layer where the environment is restricted to the context of 
the application.  This also has the effect of hiding the 
implementation of data storage from the applications,
which could be advantageous, and perhaps allowing the server
to cache information in ways the fs couldn't, if appropriate.

Such a centralized server process approach could put a considerable
load on the 'database' server (1 process per client, with 30Hz
transactions), but this can be addressed with hardware 
multiprocessing.  It also increases the number of systems required 
to support the database to 2, which could be a problem.
  
> David Butler
> gdb@dbSystems.com

Yours,

Eric Dorman
edorman@tanya.ucsd.edu