https://bugs.kde.org/show_bug.cgi?id=332013
--- Comment #9 from Martin Steigerwald <m...@teamix.de> --- I kindly ask you to reconsider. Running home directories on NFS together with some LDAP as user directory in my oppinion is a rather common use case in any organizations from companies, to universities or schools. It is used to make user data available at different work places / work stations. I read that Kontact is to be used in Munich. Heck, I don't know their setup, but I would be highly surprised if actual user data is stored on the workstations themselves. It just wouldn't make much sense to me to do that. As to whether the issue is related to NFS: Frankly, I don't know. I never saw this with another application tough. But there is a reason I believe that at least the issue is not related to the MySQL database itself: Storing journal entries via Korganizer works just fine. This also needs MySQL access for storing metadata about journal entries. Also Kmail actually lists the folders and the contains of the folders and to what I know it could do this without a working MySQL database. Hmmm, on the other hand on looking at MySQL more close, it indeed seems to have some issues. Even after akonadictl stop and akonadictl status telling that MySQL is not running, I have a mysqld process: ms 4332 0.6 0.9 2304944 115580 ? Sl Mär24 17:03 /usr/sbin/mysqld --defaults-file=/home/ms/.local/share/akonadi/mysql.conf --datadir=/home/ms/.local/share/akonadi/db_data/ --socket=/tmp/akonadi-ms.LdcAOs/mysql.socket I will check what this process is doing. Well it seems fine: mysql> show databases; +--------------------+ | Database | +--------------------+ | information_schema | | akonadi | | mysql | | performance_schema | | test | +--------------------+ 5 rows in set (0.02 sec) I also checked all tables in akonadi database all with OK results, like this one: mysql> check table parttable; +-------------------+-------+----------+----------+ | Table | Op | Msg_type | Msg_text | +-------------------+-------+----------+----------+ | akonadi.parttable | check | status | OK | +-------------------+-------+----------+----------+ 1 row in set (30.33 sec) Okay, I will now stop this process by hand with a friendly TERM signal. It excited gracefully. Now lets restart Akonadi: Well mysql is fine: akonadi.collectionattributetable OK akonadi.collectionmimetyperelation OK akonadi.collectionpimitemrelation OK akonadi.collectiontable OK akonadi.flagtable OK akonadi.mimetypetable OK akonadi.parttable OK akonadi.pimitemflagrelation OK akonadi.pimitemtable OK akonadi.resourcetable OK akonadi.schemaversiontable OK mysql.columns_priv OK mysql.db OK mysql.event OK mysql.func OK mysql.general_log OK mysql.help_category OK mysql.help_keyword OK mysql.help_relation OK mysql.help_topic OK mysql.host OK mysql.ndb_binlog_index OK mysql.plugin OK mysql.proc OK mysql.procs_priv OK mysql.proxies_priv OK mysql.servers OK mysql.slow_log OK mysql.tables_priv OK mysql.time_zone OK mysql.time_zone_leap_second OK mysql.time_zone_name OK mysql.time_zone_transition OK mysql.time_zone_transition_type OK mysql.user OK So seems that Akonadi for whatever reason didn't stop a left over MySQL process. Okay, I get the actual issue with "file to big again". Still that still running MySQL issue may be unrelated. Okay, well, to confirm whether this is NFS related or not, I will do the following trick: I do have local storage on my Workstation. I will stop Akonadi, make sure MySQL isn't running rsync -aAHXS and then symlink the ~/.local/share/akonadi onto a local Ext4 filesystem. I will open a wish list bug about making sure that Akonadi by default works well on NFS. I bet that functionality is needed for people wanting to use KDEPIM in an organization without the overhead to configure it to use a central database and keep it in sync with any locally stored metadata. Heck, since the error is with writing files to file_db_data, a central database may not even help with that. I will link this and any other possibly NFS related bugs to this wish list bug. Thanks, Martin -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug. _______________________________________________ Kdepim-bugs mailing list Kdepim-bugs@kde.org https://mail.kde.org/mailman/listinfo/kdepim-bugs