Elektrified X.org released (was: X configuration paradigm, and a proposal)

[Sean Middleditch]

On Tue, 2004-11-30 at 14:55 -0500, Neal D. Becker wrote:
> Sean Middleditch wrote:
> Are you sure?  What if you:
> 1) duplicate the directory (using hardlinks to files)
> 2) atomic rename directory

I don't believe that actually works.  You can't rename one directory
onto another already existing directory.  You'd have to move the
original out of the way, creating a window for disaster to strike.

Now, you could lock the entire hierarchy, start the move, and if it
fails in the middle (power outage, whatever) have the next process that
attempts to access the DB to "fix it."

Something like:
lock db
copy(hardlinks) db to db-work
modify db-work
rename db-work db-ready # begin danger
rename db db-old
rename db-ready db
delete db-old
unlock db

Now, if at any point between the begin/end danger lines, if the system
power shuts off or the process doing the modification crashes, a later
process can "fix" the system.  Basically, if it sees a db-ready
directory, finish up replacing db with it.

Assuming that all works as intended and doesn't have some other race I'm
not seeing, then yes, I was wrong - you *can* atomically modify multiple
files.  Sort of.  Assuming that everything that accesses them does so
using the entire process above.  Modifying even a single file would
require locking the whole DB.  Reading a file would likewise require it.
That could potentially result in a lot of over-head.  The locking could
be a huge problem for some systems running over NFS.

All in all, I'm fairly sure it's not nearly robust enough - not compared
to just a single rename of a single file.  If you're gonna go through
all that trouble, deny users the ability to just edit any of the files
directly, and so on, why not just use an existing, tested, stable
database for the backend?  BDB, SQLite, whatever - they do the same
thing the multiple text files do, plus they're a lot more efficient
about it.
-- 
Sean Middleditch <elanthis at awesomeplay.com>
AwesomePlay Productions, Inc.