LWN.net Logo

Elektrified X.org released

Elektrified X.org released

Posted Nov 30, 2004 19:08 UTC (Tue) by elanthis (subscriber, #6227)
In reply to: Elektrified X.org released by khim
Parent article: Elektrified X.org released

Because real-life users *do* use ext2/ext3, and any system that's intended to be an actual part of common Linux systems needs to take that into consideration.

The "your FS sucks, use the experimental/unstable one I prefer" approach doesn't work. Especially not when you can just fix the system to not *need* a "better filesystem." For example, just store multiple keys in one file. Not that difficult at all. Insanely simple, even.

Multiple files also making transactions IMPOSSIBLE (literally) because there is no way to perform an atomic action touching multiple files. Its as simple as that - with multiple files, the entire database is unsafe, because it can get corrupted and out of sync. Real life applications will have multiple keys that need to be in one of several states, such that certain combinations don't make sense. Without transactions and *guaranteed* atomic commits it would be possible for these states to occur in certain circumstances, resulting in broken applications.

Elektra also lacks change notification (so you still need to restart/signal daemons) and several other important features. As is, the *ONLY* thing it offers is a common API. And given the huge number of existing apps and scripts that will break by switching to Elektra, that common API just isn't worth it. Elektra also lacks features that other apps *need* like change notification or schemas, making it unusable.

The entire Elektra design can be improved upon. In fact, there are better designs already in existance. One (sorry, I forget the name - Config4GNU or something like that) uses multiple backends. So, if you set a key in the X.org namespace, it would load a backend that reads and writes the existing X.org configuration file. The advantage here is that already existing and already in-use configuration utilities continue to work while new applications can use the universal API. New applications would just use the default config backend, which would be some database or file heirarchy or whatever. Because of the backends, the system can inject a daemon that, for example, singles key changes over D-BUS allowing applications to be notified when the user changes something. By using a pluggable backend, the launching of this daemon can be delayed until after the initial system bootup, allowing the config system to be used during early-early boot with reduced features, and then become fully operational once enough of the system is up and running.

Elektra is a nice thought experimental, but it is far from the ideal implementation. It might evolve into a complete solution over time, or it might give way to Config4GNU or some other system.


(Log in to post comments)

File systems

Posted Nov 30, 2004 20:00 UTC (Tue) by tarvin (subscriber, #4412) [Link]

It's my impression that both ext2 and ext3 are getting rather good at handling directories with many files.

Elektrified X.org released

Posted Nov 30, 2004 20:18 UTC (Tue) by tzafrir (subscriber, #11501) [Link]

regarding atomic operations:

you can get nearly-atomic operations by creating a temporary file/directory copy and then mv(1) it to the right place. This does does unlink(2) and rename(2).

Anything more requires a specilized daemon,

Elektrified X.org released

Posted Nov 30, 2004 22:33 UTC (Tue) by Ross (subscriber, #4065) [Link]

That is atomic. The problem is if you are changing multiple files.

My question is why are you doing that?

But if you insist, you can do atomic operations with multiple files as long
as you don't have to have the same directory name for the old and new
version. Yes, it requires hard links or copying entire directories but
really, if a "solution" requires such ugly things then I'm quite happy to
live without it.

Elektrified X.org released

Posted Dec 1, 2004 8:33 UTC (Wed) by Wol (guest, #4433) [Link]

And why is changing multiple files any different to changing multiple places in one large file? The database I work with stores each "table" in a separate file, and yet it's quite happy with transactions and commits across multiple files.

And (certainly from the nix viewpoint) isn't the file system seen as just one large file? So, from that vantage point, updating multiple files IS just one change to one large file :-)

Cheers,
Wol

Elektrified X.org released

Posted Dec 1, 2004 16:27 UTC (Wed) by tzafrir (subscriber, #11501) [Link]

This is achived by having all accesses to those files going through a database daemon. That daemon should guarantee that locks/transactions etc. are maintained. It also caches currently-used values.

In the filesystem level the kernel does basically the same things.

Copyright © 2008, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds