[Akonadi] [Bug 360834] no mechanism to reattempt to store items without rid (just in db) into the resource
Knut Hildebrandt via KDE Bugzilla
bugzilla_noreply at kde.org
Wed Mar 23 21:55:58 GMT 2016
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.
More information about the Kdepim-bugs
mailing list