[KPhotoAlbum] Recalc checksum upon image modification?
rlk at alum.mit.edu
Mon Apr 7 03:36:19 CEST 2008
Date: Sun, 06 Apr 2008 21:14:19 -0400
From: Tim McCormack <basalganglia at brainonfire.net>
Jan Kundrát wrote:
> we don't check file checksums at startup as it's really very
> expensive operation.
*Very*, *very* expensive. It would take many hours on a reasonably
fast machine to check a large collection.
>> Is there any way of forcing KPA to do this?
> Sure, Maintenance -> Recalculate Checksum does that.
But that recalculates *all* checksums. :-/
KPA already calls stat() for all files, correct? Or does it just
check directory listings for new files?
Not any more, it doesn't. It's a bit more clever to avoid stat'ing
files it knows about or that it otherwise it knows it's not interested
in. For me, that speeds up the scan for new images on a cold system
from about 60 seconds to about 3.
stat() is fast if the inode is already in memory. If it's on disk, it
requires a disk I/O (at least one) to bring it in. My laptop disk is
5400 RPM with average 12 ms seek time. While seek times are funny
things, that means that on average stat'ing a file will (everything
else being equal) require (12 + ((60 / 5400) / 2)) milliseconds, or
about 17 ms. I have about 30,000 files in my images directory, so
that would in principle mean it would take 500 seconds if it has to
stat every file.
(In actual fact, it's much less than that -- typically about a minute,
as I said -- because multiple inodes are stored on one block, and when
the kernel reads in a block it caches it. But having to wait a minute
to start up on a cold system isn't very pleasant.)
Robert Krawitz <rlk at alum.mit.edu>
Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail lpf at uunet.uu.net
Project lead for Gutenprint -- http://gimp-print.sourceforge.net
"Linux doesn't dictate how I work, I dictate how Linux works."
More information about the KPhotoAlbum