[Digikam-users] Long database sync
caulier.gilles at gmail.com
Wed May 13 19:07:03 BST 2015
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 :
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).
More information about the Digikam-users