[Digikam-users] lots of photos and startup time

[Milan Knížek]

Gilles Caulier píše v Čt 09. 07. 2009 v 19:24 +0200: 
> 2009/7/9 Milan Knížek <knizek.confy at volny.cz>:
> > Milan Knížek píše v Út 07. 07. 2009 v 23:22 +0200:
> >> Andi Clemens píše v Út 07. 07. 2009 v 13:12 +0200:
> >> > Hmm seems to be a reiserFS problem, since every one reporting this is using
> >> > reiserFS, also the older reports are talking about reiser.
> >> >
> >> Yes, it could be reiserfs. Until recently (a week ago or so), I have
> >> been using ext3 [1] and did not notice such a long startup.
> >>
> >> Now it takes about three minutes to load 15 thousand images (the splash
> >> screen shows "reading database") for the first run after PC reboot.
> >> Iotop shows average read activity 600 kB/s. (I have 4 GB RAM on amd64
> >> with digiKam 0.10.0, ubuntu.)
> >>
> >> If I quit digiKam and start again, it takes about 5 seconds....
> >>
> >> Flushing cache does not lead to expected long startup time - just about
> >> 13 seconds.
> >>
> > Despite wories about stability, I moved my desktop single filesystem
> > from reiser to ext4 (simply backup / restore & update grub + fstab).
> >
> > Voila, digiKam starts in about 20 seconds (15 thousand images) after
> > reboot, subsequent starts are within 5 seconds.
> 
> Can you remember me the time with reiserfs ?
> 
Yes, it is actually written above - the previous email I commented was
from me.

To repeat: about 3 minutes start up time after reboot with reiserfs and
quite stable 600 kB/s disk read activity.

With ext4, the disk read was varying between 3 - 13 MB/s. Also, the
startup time is slowlier for me, since Qt/KDE libraries must load (I use
Gnome).

The dikikam4.db is 53 MB big.


A side note:
Suprisingly, digiKam lost the information about the local album location
(Album folder was empty, no images displayed). However, the database was
loaded - all tags available, time-line showing number of images. This
should not happen, I have used rsync -av to backup and restore, the only
things which probably changed were the partition UUID and underlying
filesystem.

In the Settings / Collections there was "Images" shown under local
collections, but the path information was empty. Removing this
collection and adding back (media/Data/Photo/Images) resulted in
scanning all images again and now things seem to work as expected.

regards,

Milan Knizek
knizek (dot) confy (at) volny (dot) cz
http://www.milan-knizek.net - About linux and photography (Czech
language only)