In T13298#233444, @jackyalcine wrote:

To be honest, this is something I wanted to contribute. I've had moments as I'd code that my computer would lock up and it was because baloo was indexing pictures (not even the source code). I'm not sure but it's not explicit that Baloo runs only when the computer is idle. I'd want to extend this to communicate:

• How much time / progress is made for a full index

We need a unique identifier per inode namespace, and for btrfs this is per subvolume and not per disk. Currently, baloo uses QStorageInfo to obtain what it needs. I'll look into Solid and udisks but I fear they will be per disk only, too.

I don't think Baloo should store an index right on the filesystem it's going to index just to get rid of the device id. It seems tempting but I can think of multiple problems:

Looks like looking up the FS UUID can only be done by root (it involves libblkid reading the superblock directly). Does the kernel have some syscall to look that up, or why doesn't it? Also, st_dev is not stable on btrfs (and many other FSes that use virtual devices).

Here's a quote:
https://github.com/bmatsuo/lmdb-go/issues/118#issuecomment-325449496

Added depend line according to arc docs

Resend diff with arc

Using single-patch-per-branch approach

Now arc squashed all my commits into one single diff... I'm not sure if I like that.

Rebase and submit with arc

In D24539#545019, @ngraham wrote:

This doesn't apply cleanly on master. Can you rebase it?

My submission didn't work as expected...

Prevent filesystem thrashing in low-mem situations by turning off
read-ahead. Access patterns of baloo are unlikely to benefit from
read-ahead and preserving cache is more valuable than reading ahead
potentially unused data.

Let's close this in favor of D24502

I think we can also assume that using possibly unlimited recursion is also not good practice.