[Akonadi] [Bug 332013] on moving a mail: ItemRetrieverException: Unable to retrieve item from resource: NO PartHelperException, unable to open for writing, file too big

[Martin Steigerwald]

https://bugs.kde.org/show_bug.cgi?id=332013

--- Comment #9 from Martin Steigerwald <ms at 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.