[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Status of gconf -> dconf

On Tue, 2009-02-24 at 08:42 -0500, Simo Sorce wrote:

> Seth, the fact that sqlite or other db-style files have problems on some
> networked filesystem either indicate a bug in the db or in such
> filesystems.
> NFS(v2/3) is known to be a bad file system, sure it "mostly" works for
> users, but has so many problems I do not even care to think anymore
> (riduculous locking, stateless, no decent client caching ...).

nfs v2/v3 are known to be filesystems in common use. They are also known
to be the filesystems that worked with multiuser configurations in the
past. It's not like this has been a problem for networks all along and
people only suddenly realized it.

When I started managing shared resource unix/linux systems a decade ago
multiple logins to multiple desktops were running all the time. Hell, in
many cases the end-user systems didn't even have local disks to speak

Somehow we managed with nfsv2.

> NFSv4 and CIFS should be much better, is sqlite breaks on these
> filesystems there are perhaps bugs in their client kernel components.

> It would be better to fix the FSs rather then just ditch the problem
> completely.

It might be worthwhile to ask what the features are we're getting out of
moving things to sqlite, for example, before deciding that there is a
problem to be fixed at all.

The foregone conclusion seems to be that we have to add data-rich
features. I don't think that's a good given.

> That said, given home directories must stay on a trusted server anyway,
> building a central daemon that the networked desktops can use instead of
> trying to open databases over networked filesystems (performance sucks
> when opened from multiple clients) is also a good idea.

central daemons are a problem unless they are designed like filesystem
infrastructure are designed: fault tolerant, capable of fail over and
redundant. And configuration daemons have, in the past, been designed
very poorly and/or horribly over engineered (ACAP as an example, ORBit
as another).

We need to NOT lock out one set of users for another set of users.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]