Status of gconf -> dconf

Simo Sorce ssorce at redhat.com
Tue Feb 24 15:53:41 UTC 2009


On Tue, 2009-02-24 at 10:14 -0500, seth vidal wrote:
> On Tue, 2009-02-24 at 09:23 -0500, Simo Sorce wrote:
> 
> > oh but it has, ever tried to do locking on nfsv2/3 ? No? Wonder why most
> > apps have been working around proper locking inventing abominations like
> > lockfiles and other 1000 non standard and all incompatible ways to mange
> > locking because it was always broken on NFS ? To the point that now 99%
> > of unix apps don't even acknowledge nor test for locks on files and die
> > hard is locks are mandatory or just completely ignore them if they are
> > advisory (making advisory locking almost useless).
> 
> let's not chase off down solely the nfsv2/v3 path. There is also afs
> (which is still deeply entrenched in a number of big .edus, for better
> or worse) and you may be able to speak to this best but istr cifs-linux
> didn't play all that nicely on samba v3 and sqlite.

File bugs please.

> > > 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
> > > of.
> > 
> > Yes, when I started a decade ago I had similar setups, I am *not*
> > advocating breaking networked home directories, but boy, we have to stop
> > making up systems that sucks only because people *insist* on using a
> > broken network filesystem.
> 
> Show me the fixed network filesystems, then. Making decisions based on
> theoretically deployable (but not really) fs seems like bad planning.

And I concur that it would probably be.

> > > Somehow we managed with nfsv2.
> > 
> > yes, *somehow* I managed too and it was bitter hate. Isn't it time to
> > fix our stuff to work well and not "somehow" ?
> 
> Or maybe it's time to acknowledge that making apps which play with the
> existing systems is simpler than converting all the existing systems.
> 
> And it's not like apps breaking things in nfs is a new thing. When gconf
> was first introduced it made multiple, simultaneous logins impossible.

I know, I didn't say I like that, but at the same time, we shouldn't
just surrender. We have means to fix stuff, let's fix it at the right
layer, instead of entrenching more and more in workarounds that put less
pressure on the layer that should be fixed instead.

> > It's not like we can't change protols today. Back then the NFS server
> > was an old Unix machine, with proprietary software we could not touch,
> > today we have Linux servers, I think we can fix stuff, and *surprise*,
> > we have NFSv4 and CIFS that do a *much* better job at serving out files
> > with decent semantics.
> 
> Does cifs-linux actually do that? Does it behave with sqlite? 

Have not tested, but if it does not, it should be fixed.
Mind you I don't know if sqlite is bug free either, if it uses mmap and
expect it to always be coherent instead of properly using
msync/fsync/locks than it may break over the network (and some non-linux
systems too).

At the moment I know of some work we should do on cifs.ko to better
handle mmap coherency (though problem over the network).

> > > > 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.
> > 
> > As you well know some apps will use (and do use, like Firefox,
> > evolution, ..) sqlite already, it's late to ask if it is good or not,
> > its time to fix whatever need fixing if they do not work with
> > NFSv4/CIFS.
> 
> 
> I don't think it's too late to put the genie back in that bottle, or
> alternatively, to change where genie stores its frelling sqlite files.
> Tmp spaces are not unthinkable and last-in-wins behavior for multiple
> logins.

I am all for addressing current problems, I am just not ok writing them
off and not fixing our networked file systems.

> > > The foregone conclusion seems to be that we have to add data-rich
> > > features. I don't think that's a good given.
> > 
> > Make a better proposal, but just screaming: "this breaks on broken
> > NFSv3!!" does not seem like anything useful to me, sorry.
> 
> Why is it unreasonable to ask that client applications not attempt to do
> things outside of the capabilities of the server?
> 
> Q. Doctor, Doctor, it hurts when I do this!
> A. Then don't do this.

Q. Doctor but if I do not do this, that happens and hurts as well
A. Amen (?)

> > Sure, there are requirements to be met, you think I'd advocate for
> > broken daemons after ranting about broken filesystems ?
> > However they do not need to be more fault tolerant than current
> > filesystems where you put your home on.
> 
> Show me a daemon that is as fault tolerant as filesystem daemons AND
> handles the authN/authZ like a filesystem does. Any daemon, please.

Just out of my mind and current experience: Directory Server, openLdap,
etc ...

But I am *not* advocating using an LDAP server for personal
configuration files.

> > > We need to NOT lock out one set of users for another set of users.
> > 
> > No, we should not, in either direction.
> 
> Except I'm not asking for anyone to be locked out - I'm asking for app
> developers to not get locked into this world view of "well if it works
> on my laptop then surely it'll work everyone else, everywhere."

I totally agree here, that's why I say: " fix the filesystem first "

> Sqlite in firefox is fine - but it's far from a requirement to use the
> web. Make the sqlite use optional, make the destination dirs deal with
> tmpfiles.

While I understand the issue, FF people may reply: why don't you fix
your filesystem instead ? I am not saying it is the right answer, but it
is a legitimate answer.

> There are a ton of reasons why relying on local-drive semantics are
> doomed - I mean look at expiring kerberos tickets as another reason.
> Something that never happens on local-drive logins is that the user's
> rights to access their homedir suddenly and completely go away. Having
> the system even barely remain functional isn't an unreasonable request.

I totally agree that a ram/local disk where you keep temporary data
would be a neat idea. But are you going to fix all apps to use it ? :-)
(pun intended :-P)

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York




More information about the fedora-devel-list mailing list