File indexing for Ext3

Hallo everyone.

I am trying to get my system to enable file indexing, in order to speed up file searches using Dolphin. I tried following the directions found here:

Speeding up Ext3 - openSUSE

I used an Ubuntu Live CD (sorry, it was the only one I had available), and then I tried using the repair feature of the OpenSUSE DVD.

When I run the tune2fs -O /dev/sda6 command (sda6 is my openSUSE root partition, with Ext3 FS), nothing really happens. I get a message from tune2fs stating the date of tune2fs, but nothing else. When I subsequently run e2fsck -D /dev/sda6, it just gives me a summary of the available blocks, stating that the filesystem is clean, and the number of blocks or whatever.

Is there a way to check whether or not file indexing has been enabled? So far, the only way I have come up with is trying to perform a search using Dolphin, which does not allow me to check the “Use files index” option at all (it’s grayed out).

Is the search feature of Dolphin connected to the file indexing feature of Ext3 or am I going about this the wrong way? Is there another way to check if file indexing has been enabled? Why don’t tune2fs and e2fsck appear to do anything?

Thanks in advance!

In SUSE beagle is installed by default, however I delete it, as do many others. In kde4 you can enable strigi
Config desktop -Advanced - Desktop search -
Check the strigi box

Ok, I enabled Strigi but the “Use files index” option in Dolphin (which actually uses Kfind) is still grayed out. Any other ideas?

Thanks, BTW!

Ah, both of you are a bit confused.

@saverios: It actually directory indexing, if you read that article more carefully. It speeds up access in large directories. You’ll probably find it’s already enabled by default, a tune2fs -l should show you. Otherwise do:

tune2fs -O dir_index /dev/sda1

for example to enable it as described in the article.

The atime tips in that article are good though, I have atime disabled on my filesystem. But you will only see a difference on heavily loaded filesystems since it reduces the number of writes.

@saverios & caf4926: This dir_index feature has nothing to do with free-text indexing of files done by beagle or strigi. This is a Linux ext3 filesystem feature.

Thanx for clearing that up, Ken. Running tune2fs -l shows that directory indexing is indeed enabled, so that is one less thing to worry about. So, how do I make KFind use a file index? I assume this will speed up the searching process. Strigi is enabled, as caf suggested.

Sorry. Yes, I see.
The section: Speeding up Ext3 - openSUSE
Quotes using openSUSE or Knoppix but if makes any difference that you used Ub* I doubt it it.

Personally I never bother with all this optimization stuff and don’t use file indexing of the dir tree of my installation either.

@ken_yap I defer to your superior knowledge anyway!

Ok, I think I got it.

Apparently, KFind (which is the module Dolphin uses) uses the ‘findutils-locate’ package, along with some other packages that allow KFind to use a file database created by the utilities in this package. This installs an additional script that is run daily and updates a database of all the files in the system.

The updating process takes a long time, though, and is not very practical. I ended up removing it, as it takes about 3-4 minutes to update and during that time the system is sluggish. I think it’s meant for systems that are never (or not often) shut down, or maybe use multiple disks.

Thanks for all your help, guys. Problem solved!

Yes, updatedb, the process that builds/rebuilds the indices can slow down things.
If you want real speed, buy a 32GB SSD and use that for install. No filesystem tuning is going to beat that. IMHO a system like yours should have one.

Thanks for the suggestion, Knurpht. I’ll certainly keep it in mind. One question, though: The wikipedia article on SSDs, Solid-state drive - Wikipedia, the free encyclopedia

, says that the repeated writing / erasing of SSDs reduces their effective lifetime, and that this should be taken under consideration when using such a disk for booting an OS (which involves much reading / writing.) Do you know anyone who has actually done this to give me a sense of the reliability of the SSD in such an environment?