[Digikam-users] Long database sync

[Gilles Caulier]

2015-05-10 23:54 GMT+02:00 Noeck <noeck.marburg at gmx.de>:
> By Henrique Santos Fernandes:
>
>> So it is going trought all you pictures and writing the data in it.
>> Thats maybe why that much disk activity.
>
> Thanks for your reply. 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.

>
> 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 ?

> The database only grew from 89 MB to 91 MB.

This value is correct.

>
> My guess was that the database is updated for each file seperately and
> completely, no matter whether it contained changes or not.

yes.

> Such that all
> this amount of written data replaces the previous content – this would
> explain why no additional space was used (free space on disk only
> reduced by a few MBs).

yes

>
> The thumbnails-digikam.db was not updated at the same time (no time
> stamp change). It has 950 MB.

size can be correct as it use PGF wavelets compression image data
(before following desktop.org paper, we unse PNG which square size
easily).

>
> 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 ?

Gilles Caulier