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

[Ingo Klöcker]

On Sunday 03 April 2011, Martin (KDE) wrote:
> Am Samstag, 2. April 2011 schrieb Kevin Krammer:
> > On Friday, 2011-04-01, Martin (KDE) wrote:
> > > Am Freitag, 1. April 2011 schrieb Kevin Krammer:
> > > > I don't think Akonadi uses this right now for file bases
> > > > caches, but that should probably be investigated.
> > > 
> > > until 4.5.5 akonadi uses .local/share/akonadi for the database.
> > 
> > Up until 1.5.1 :)
> > (which is the most recent release AFAIK)
> 
> Yeah, true. Sometimes I get confused with all the different numbers.
> 
> > And I was not talking about the database per se. Akonadi basically
> > has a size limit up to which it puts cache data into the database
> > as well, utilizing cache files for anything above that.
> > 
> > Assuming the desire to have cache data separate, one could
> > configure this limit to be very small, probably zero.
> > Thus the database will then only contain state and relational data.
> > 
> > One kind of cached data might still be better be in a data
> > location, i.e. data not yet uploaded to the actual backend (e.g.
> > server).
> 
> I am not sure that this should be an online database like mysql.
> Mysql is not supposed to run on NFS file systems. For non plain
> cache data a xml file may be an idea. this file (or files) can be
> stored in the home directory.

The problem is not mysql. The problems are concurrent file system access 
and change notification. It's irrelevant whether you store the 
information via a database or directly in files (replicating the complex 
functionality databases already provide).

In fact those problems are precisely some of the reasons why we came up 
with Akonadi. Akonadi (with its database backend) serves as single point 
of access for everybody who is interested in PIM data. Since the Akonadi 
server is a single process concurrent file system access is a non-issue. 
Also Akonadi server notifies interested parties about changes.

One of the main design decisions for Akonadi was that it serves only one 
user on one computer. We explicitly excluded problems caused by multi-
user and multi-computer support to keep the task manageable. It still 
took more than 5 years.


> At the end there are the configured sources. These data (at least
> partly) are cached in the database which is located somewhere in
> /var/tmp. All the additional data someone adds to pim sources that
> can not be stored in the pim source itself may be stored in a file
> (or offline database) and synced every now and then.
> 
> AFAIK all modern enterprise network file systems out there supports
> file locking.

When I last looked into NFS it still had severe problems with file 
locking. Anyway, file locking is the poor man's solution for the problem 
of concurrent file system access and it doesn't solve the much more 
important problem of change notification. All you know is that something 
has changed. To find out what has changed you have to re-read the whole 
file and compare it to the information you have in memory. That's 
exactly what we did before Akonadi and it was a major pain in the ass.

But all of this is mostly irrelevant. I think we all agree that the 
solution for the problems with NFS is to avoid the usage of NFS by 
storing Akonadi's cache not in the user's home directory but in /var/tmp 
(or /var/cache ?).


Regards,
Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kdepim-users/attachments/20110403/ee829e35/attachment.sig>
-------------- next part --------------
_______________________________________________
KDE PIM users mailing list
Subscription management: https://mail.kde.org/mailman/listinfo/kdepim-users