https://bugs.kde.org/show_bug.cgi?id=437019
--- Comment #3 from tagwer...@innerjoin.org ---
(In reply to David Kredba from comment #2)
> Total files count is constant, I tested moves of existing files. Found it
> when I needed to ran rsync over ssh in the morning being short on time and
> saw its slowness so went to check what is slowing the disks down. Found
> indexing of content of files where there was zero to be indexed the day
> before session log-off (shut down of the machine).
Well, baloo is only "there" when you have logged on. If you connect to your
$HOME with rsync/scp and change things then baloo won't have got any inotify
msgs and it will discover changes when you log on and it starts up. In the case
that rsync updates modification times, baloo thinks it should reindex.
Whether this has an impact of your 'mv' issue, not sure...
> find . -type f | wc -l returns 503013, so there is a reserve for inotify.
Luckily the inotify watches are there for folders, not individual files.
> When I tried "balooctl check" after files moved it not started to index and
> the count of files waiting for indexing stayed at 0. Each time I tested it.
>
> I will test the stat case.
Gut feeling is that you are OK. There's another test tool you can use though:
balooshow -x oneofyourfiles
which looks up the entry for the file in the search index. It knows which file
is which based on the device number/inode (as per the "stat" command)
You can have a look at
https://bugs.kde.org/show_bug.cgi?id=402154#c12
> Is noatime fine for baloo please? (maybe it can be that simple)
> LABEL=HOME /home ext4 noatime
My "Neon Testing" machine has
/dev/vda1 on / type ext4 (rw,noatime)
so you are not alone :-)
--
You are receiving this mail because:
You are watching all bug changes.
