[kdepim-users] Re: Akonadi + nfs home directories

[Martin (KDE)]

Am 11.04.2011 23:27, schrieb Ingo Klöcker:
> On Tuesday 05 April 2011, Martin (KDE) wrote:
>> Am Dienstag, 5. April 2011 schrieb Lars Behrens:
>>
>> I think it is due to all the databases laying around. In the old days
>> with text based files only this is no problem. Altering database
>> files from two (or even more) different host will kill it (sooner or
>> later).
> 
> Just for your information, the index files KMail1 used (and which are 
> nothing else but poor man's db files) were never intended to be used 
> from two (or even more) instances of KMail. In fact, I am 100 % sure 
> that you would corrupt the index and probably would lose mail if you 
> would access and modify the same folder with two instances of KMail1.

I know. To me this was no problem as I usually don't login on two
different computers with the same user. My point was a different one.
Almost all modern programs (thunderbird, firefox, darktable, digikam
...) that uses a amount of data stores this inside a database. some of
them uses the home directory by default or even don't give the user an
option to change the location. So this problem is not bound to kde pim
(akonadi) but a general one. I don't know a way around this besides
syncing the home folder to/from the server.

> 
> KMail1 doesn't do any locking whatsoever for anything stored in $HOME. 
> But it warns you if it thinks that another instance is running. It's 
> sheer luck if concurrent access doesn't result in data loss.
> 
> You are mourning the loss of functionality that never existed in KMail 
> namely proper support for data storage on NFS shares and concurrent 
> access to this data.

Again, my point is different. I had the hope that the situation improves
with akonadi. But on the long run I will no longer use NFS home
directories (at least on most computers). As all my users uses their
home directory exclusively from one computer this is no problem anyway.

> 
> 
>> If the db files were used for caching data only they can be moved to
>> another place (/var/cache or similar) but modern programs even stores
>> configuration data into db files.
> 
> Akonadi and KDE applications do not use a db for configuration data. KDE 
> PIM uses Nepomuk for storing meta-data (e.g. contact groups, message 
> flags, etc.). Nepomuk uses a db as backend.

So nepomuk is affected by this problem as well.

> 
> 
>> Configuration have to be stored in
>> users home directory. Even if you split cache db from config db the
>> problem will remain. If both programs try to store their
>> configuration into the db at the same time it may be get corrupt.
>>
>>> With all the cloud mania these days we are testing the use of
>>> terminal server atm, maybe this might be the way to go, a bit
>>> ridiculous though, with a herd of dual core machines being used as
>>> terminals :-\
>>
>> But why don't you want to sync the home directory from/to the server
>> at login/logout? May be Microsoft is not the reference here, but they
>> do it since the beginning (at least can do).
> 
> Because they cannot be bothered with logging out. Apparently, they want 
> to be logged in on multiple computers and use KMail simultaneous on 
> those computers. As if that would have worked reliably before Akonadi.

This will only work reliable wit something like VNC with different views
to one desktop. May be it is time to develop something like persistent
and shared X connections. But AFAIK current development is going into
opposite direction.

> 
> 
>> And terminals don't get around the problem. If a user is logged in
>> twice the programs will run twice as well. Only if the user gets two
>> different views of the same desktop this will work. But I don't know
>> of any system implementing this.
> 
> VNC

Hmm, I don't like VNC that much. It is a little bit slow and different
from X and RDP. But I don't use it regularly so my knowledge about it is
limited.

> 
> 
> Regards,
> Ingo

Greetings
Martin
_______________________________________________
KDE PIM users mailing list
Subscription management: https://mail.kde.org/mailman/listinfo/kdepim-users