https://bugs.kde.org/show_bug.cgi?id=472493

            Bug ID: 472493
           Summary: Baloo does not respond when catching up with file
                    deletions
    Classification: Frameworks and Libraries
           Product: frameworks-baloo
           Version: 5.107.0
          Platform: Other
                OS: Linux
            Status: REPORTED
          Severity: normal
          Priority: NOR
         Component: Baloo File Daemon
          Assignee: baloo-bugs-n...@kde.org
          Reporter: tagwer...@innerjoin.org
  Target Milestone: ---

SUMMARY

    Baloo removes entries from its index as files are deleted. However this
    process blocks actions such as "balooctl disable", meaning that if baloo is
    busy, it does not respond to an request to close down

    An associated" issue is that baloo queues up indexing new or changed files
    until after it has caught up with the deletions. You don't see "balooctl
check"
    having an effect.

STEPS TO REPRODUCE:

1...

    Make sure you have content indexing enabled and are indexing your test
directory

2...

    Run "balooctl monitor" and "htop"

3...

    Create a test directory with many files, following the steps in Bug 437754:

            for i in {00001..50000}; do echo "This is file $i" > file$i.txt;
done

    and wait to see that all the files are indexed. Delete 1000 of these files:

        rm file20*.txt

4...

    Create a test file

        echo "Hello Penguin" > testfile.txt

    and watch the "balooctl monitor" results, try a "balooctl check" and then a
    "balooctl disable"

OBSERVED RESULT

    The test file only seems to be indexed after baloo has finished cleaning up
    the deleted file records. It is not possible to follow deletions with
    "balooctl monitor" or with logging but you can see the file indexed when
    the CPU usage drops.

    The "balooctl disable" also only happens after the cleanup is complete; you
    get a "Disabling and stopping the file indexer" message but the process
    keeps running.

    Removing files from the index is markedly slower than the initial content
    indexing (which deals with files in batches). You can watch with iotop:

        sudo iotop

    and see baloo_file committing to disc after removing each file.

EXPECTED RESULT

    Baloo should respond quickly to a "balooctl disable" and should also, as
    preference, interrupt the cleaning up of deleted files in order to index
new
    or changed files (for example after a "balooctl check")

SOFTWARE/OS VERSIONS

    This was tested on Fedora 38 (that has the BTRFS patch)

        Fedora Linux 38
        Plasma: 5.27.6
        Frameworks: 5.107.0
        Qt: 5.15.10

-- 
You are receiving this mail because:
You are watching all bug changes.

Reply via email to