| |||||||||||||
|
| |||||||||||||
Elektrified X.org releasedElektrified X.org releasedPosted Nov 30, 2004 17:52 UTC (Tue) by khim (subscriber, #9252)In reply to: Elektrified X.org released by evgeny Parent article: Elektrified X.org released
What's wrong with fs approach ? Any decent filesystem (i.e.: not ext2/ext3) can handle 1'000'000 files per directory and 10'000 directories with ease and without big space loss. XFS, JFS, Reiser4 - take your pick.
(Log in to post comments)
Elektrified X.org released Posted Nov 30, 2004 19:08 UTC (Tue) by elanthis (subscriber, #6227) [Link] 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.
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
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,
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.
Elektrified X.org released Posted Nov 30, 2004 19:10 UTC (Tue) by busterb (subscriber, #560) [Link] To expand on this, the best backend is one that supports tracking revisions and rollbacks. Perhaps a CVS/Subversion backend, since they both can store data in relatively plain files? We already use Subversion for tracking changes to /etc, so this would be a natural extension.
Elektrified X.org released Posted Nov 30, 2004 20:29 UTC (Tue) by tzafrir (subscriber, #11501) [Link] You can easily maintain everything using version control (you'd probably want something that supports renames).
All you need is to make sure that there is always an up-to-date copy of the configuration file in the right place.
Elektrified X.org released Posted Nov 30, 2004 21:12 UTC (Tue) by LogicG8 (guest, #11076) [Link] > the best backend is one that supports tracking revisions and rollbacks.
I really have to disagree. Revision control systems are complicated
$ ldd /usr/bin/svn | wc -l
And that doesn't even count the dependencies of svn's dependencies... I
My reasons for actually liking this system:
1) Ability to hand edit config files. If I'm working over ssh (and I do
2) Independence of data. If you've ever had a chunk of the registry
3) I can easily copy/save specific configuration data. With database
4) I can have comments.
5) This can be combined with MACs (mandatory access controls) or ACLs
6) This one is only speculation on my part but corruption can only happen
7) No new paradigms to learn. I know how get around in a filesystem.
8) Easy program interaction. I'll be thrown out of the *nix geek club for
9) More shared code. One less thing to worry about.
Elektrified X.org released Posted Dec 1, 2004 0:30 UTC (Wed) by emkey (guest, #144) [Link] >"8) Easy program interaction. I'll be thrown out of the *nix geek club forsure for saying this but I *like* GUI configuration programs. I like things to be easy."
As do most of us. The problem being GUI's don't for the most part scale worth a dang. In general GUI's are fine, but they should always be considered secondary to some sort of CLI interface. The problem is many vendors get it backwards, or worse yet don't implament any sort of CLI.
Elektrified X.org released Posted Nov 30, 2004 20:09 UTC (Tue) by evgeny (guest, #774) [Link] Well, ext2/ext3 is a filesystem of choice for a very significant (probably still major) part of Linux users. Further, apache/bind/.... will NEVER officially use anything that's available for Linux only (and other Unices don't necessarily have all that advanced filesystems).
But more importantly, a dumb fs-based config is just that: a dumb one. Whereas a decent configuration system should provide for logical expressions, remote management, replication, versioning, transactions/rollbacks etc. All this is practically impossible with a filesystem-based config tree; and all this is posssible with RDBMS.
Elektrified X.org released Posted Nov 30, 2004 22:45 UTC (Tue) by khim (subscriber, #9252) [Link] But more importantly, a dumb fs-based config is just that: a dumb one. Whereas a decent configuration system should provide for logical expressions, remote management, replication, versioning, transactions/rollbacks etc. All this is practically impossible with a filesystem-based config tree; and all this is posssible with RDBMS. If your filesystem is dumb - it's not possible. If your filesystem is smart - it can be done. True - it should be supplied as addon over simple system but all-in-one solutions are never good.
Elektrified X.org released Posted Dec 1, 2004 10:31 UTC (Wed) by evgeny (guest, #774) [Link] > If your filesystem is dumb - it's not possible. If your filesystem is smart - it can be done.
So we can return to this discussion when every man and his dog have such smart filesystems - including embeded devices etc.
Elektrified X.org released Posted Dec 2, 2004 10:08 UTC (Thu) by szh (guest, #23558) [Link] Don't forget to also return to the fact, that not every man and his dogwant replication, versioning, transactions/rollbacks etc. And many of those who need, can do this with filesystems + there own scripts. Just regular cron /etc [or parts of /etc] [incremental] backups satisfy many men and dogs. So the new system will give drawbacks only for those men and dogs.
Elektrified X.org released Posted Dec 2, 2004 10:28 UTC (Thu) by evgeny (guest, #774) [Link] > Don't forget to also return to the fact, that not every man and his dog> want replication, versioning, transactions/rollbacks etc. > And many of those who need, can do this with filesystems + there own > scripts.
Continuing this nice logics, there is no need for a unified configuration system altogether - just as everyone has been adjusting dozens of different configs during the last twenty years of mainstream Unix usage, so we can do it further on. Right?
Elektrified X.org released Posted Dec 1, 2004 0:45 UTC (Wed) by tzafrir (subscriber, #11501) [Link] remote management etc. is beyond the scope of Elektra. Electra is not aware of the semantics of the configuration. It just provides a simple method of accessing configuration.
Adding remote management, versioning on top of that is proably possible.
The main non-standard feature required for Elektra to work propely is symlinks. And even without it most things will work. Other than that all you need is basic file-system interface.
Elektrified X.org released Posted Dec 1, 2004 10:47 UTC (Wed) by evgeny (guest, #774) [Link] > remote management etc. is beyond the scope of Elektra. [...] It just provides a simple method of accessing configuration.
Exactly. It, essentially, implements the day-before-yesterday functionality (INI configs) yet requires facilities not present in all current filesystems.
> Adding remote management, versioning on top of that is proably possible.
Well, the keywords here are "on top" and "probably". ;-) With the same expected level of success as adding security on top of DOS was. It just strikes me that a project with such an ambitious goal as converting _all_ the Unix configuration mess to a single API didn't bother thinking of even yesterday's requirements to system configuration!
Elektrified X.org released Posted Dec 2, 2004 23:07 UTC (Thu) by tzafrir (subscriber, #11501) [Link] > Exactly. It, essentially, implements the> day-before-yesterday functionality (INI configs)
No, it is not INI config. With INI config you have only thre-level deep tree of configuration (file, section, key). Electra does not have this silly limitation.
> yet requires facilities not present in all current filesystems.
The *required* facilities are avilable everywhere. On some systems it will be less efficient. But even ext3 now has support for a more scalable directory access . Try tune2fs -O dir_index
> Well, the keywords here are "on top" and
Rebuilding everything from scratch has even less expected chance of adding security.
> It just strikes me that a project with such
Into a system that is easy to use by eveything and can be used anywhere.
Elektrified X.org released Posted Dec 3, 2004 19:49 UTC (Fri) by evgeny (guest, #774) [Link] > How can you configure the network using this daemon if the networked daemon needs the network configuration just to get going?
In exactly the same way I can run a LDAP server holding the user DB under a given account. Also, think e.g. of gcc bootstrapping, running of fsck on / before anything is mounted etc. We have a lot of similar chicken-or-egg problems.
|
|
||||||||||||