[Digikam-users] Long database sync

[Gilles Caulier]

2015-05-13 19:18 GMT+02:00 Noeck <noeck.marburg at gmx.de>:
> Hi Gilles,
>
> thanks for your reply and for confirming my guesses. Please find answers
> to your questions inline.
>
>>> I chose "From image metadata to database" and not
>>> "From database to image metadata", so according to my understanding,
>>> only the database changes. And indeed the image files were not modified
>>> (according to the file system).
>>
>> yes exactly, but... image metadata must be read to re-populate DB.
>> It's delegate to Exiv2 shared library.
>
> Ok. But read not written and the system monitor showed it as written.
>
>>> In the end, the mentioned database sync took 25h with a constant write
>>> rate of 12 - 15 MB/s. Which naively calculated sums up to 1.2 TB (!).
>>
>> I don't understand this value. Are you sure that 15 MB/s is for
>> writing and not reading ?
>
> Yes. This is what astonishes me.
>
>>> What puzzles me is that the sum of all images is only 200 GB (50k files)
>>> so much less than the data written to disk.
>>
>> Possible problem can be relevant of a bug about wrong albums list
>> passed to maintenance tools, discovered recently and fixed in 4.10.0
>>
>> Q : did you use multicore option in Maintenance dialog ?
>
> No this was done without the multicore option. So there might be some
> gain here. However it seems pretty much i/o bound.
>
> And I chose all albums and all tags (no selection here). I was wondering
> if that scans all files twice?

yes, i suspect this. Look this entry in bugzilla :

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

This affect Thumbnail Generator, Quality Sorter, and Fingerprints Generator.

We must take a look if other maintenance tools are affected (in your
case DB synchronizer).

Gilles Caulier