[Akonadi] [Bug 360834] no mechanism to reattempt to store items without rid (just in db) into the resource

[Knut Hildebrandt via KDE Bugzilla]

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

Knut Hildebrandt <knut.hildebrandt at gmx.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |knut.hildebrandt at gmx.de

--- Comment #5 from Knut Hildebrandt <knut.hildebrandt at gmx.de> ---
Hey Martin,

since you marked https://bugs.kde.org/show_bug.cgi?id=344242 a duplicate of
this I continue here.

In the other bug report I have written about my experience with data loss and
described a workaround to make sure that data - in my case emails - will be
copied were they belong - in my case local mail folder. Nevertheless one
problem remained, the growth of ~/.local/share/akonadi/file_db_data. After a
couple of weeks it holds again tens of thousands of items. 

After reading what you recommended to Guido I also ran "akonadictl fsck" which
brought up quite a few items without RID. But it also said it had found loads
of items without a reference in the database. Unfortunately I did not redirect
the output to a file and thus most of it is lost. What I still could see are
many entries like this:

Migrated part 1324911 to new levelled cache

When I started it again I got following output:

[knut at chakra-pc ~]$ akonadictl fsck
Looking for resources in the DB not matching a configured resource...
Looking for collections not belonging to a valid resource...
Checking collection tree consistency...
Looking for items not belonging to a valid collection...
Looking for item parts not belonging to a valid item...
Looking for item flags not belonging to a valid item...
Looking for overlapping external parts...
Verifying external parts...
Found 1946 external files.
Found 1944 external parts.
Found unreferenced external file:
/home/knut/.local/share/akonadi/file_db_data/771220_r2
Found unreferenced external file:
/home/knut/.local/share/akonadi/file_db_data/771240_r1
Moved 2 unreferenced files to lost+found.
Checking size treshold changes...
Found 0 parts to be moved to external files
Found 0 parts to be moved to database
Looking for dirty objects...
Collection "Search" (id: 1) has no RID.
Collection "OpenInvitations" (id: 28495) has no RID.
Collection "DeclinedInvitations" (id: 28496) has no RID.
Found 3 collections without RID.
Item "649909" has no RID.
.
 here came many more RID entries
.
Found 87 items without RID.
Item "499424" has RID and is dirty.
Found 1 dirty items.
Migrating parts to new cache hierarchy...
Consistency check done.

When I checked ~/.local/share/akonadi/file_lost+found I saw that most of the
files that had been in "file_db_data" before invoking "akonadictl fsck" were
moved there. Now "file_lost+found" holds more than 2GB of files whereas
"file_db_data" only holds less than half a GB.

Now I wonder it it is save to delete all the files in "file_lost+found" to get
disk space back? Or will this cause loss of data? Deleting files in
"file_db_data" caused massive data loss.

Knut

-- 
You are receiving this mail because:
You are the assignee for the bug.