A question for the linux guys (slocate/updatedb related)

[f0dder]

I've recently gotten interested in power consumption, and thus I spin down the RAID array in my fileserver when it's not needed for an extended period of time.

However, slocate (updatedb), which is scheduled nightly, spins up the disks, which is pretty counter-productive. I've added the mount point to PRUNEPATHS of /etc/updatedb.conf, which does seem to partially help: I can no longer locate files in /mnt/raid , and the updatedb process seems to be significantly faster.

But updatedb still spins the drives up. Any ideas?

[Edvard]

Is the RAID array on the same cable path as your main drive? It may be a hardware issue, like waking up one disk wakes up the entire array. If that's the case, I wonder if it's something you can tweak in the RAID configuration or even the BIOS.
Also check your cron configuration. It may not be updatedb at all, but a cron entry that is scheduled for the same time, but doing something completely different.
Some (slightly outdated) advice from the good ol' interwebs on saving laptop power:

  * disable all useless services. (sendmail, shell, rpc, etc)  Usually this
    is done from /etc/rc.* scripts.  Note this won't directly affect battery
    life but it will keep the hard disk spinning if a daemon has too many
    files open and keeps writing to them.
  * Don't run cron, at, updatedb, and other disk-spinning daemons.  For
    timed tasks, I found the at daemon that comes with Slackware to be the
    least disk-spinning.

Of course, the stuff you disable in cron you'll have to run manually. Before I discovered cron, I wrote a shell script that would run updatedb and flush /tmp and a few log files. I made it the last thing I would do before detaching going to bed or the first thing after logging in and making coffee.

Of course, I'm not running a RAID array nor a fileserver, just a lowly desktop workstation.

Hope this helps.

[f0dder]

It is updatedb causing it, since I've manually run updatedb wihch also triggers the spin-up.

Cable path is irrelevant, SATA drives have one drive per cable. But even for IDE, the drive should only wake up if it's the one receiving a command, not if another drive on the same cable receives.

The fun thing is that I added /mnt/raid to the PRUNEPATHS config line for updatedb, but it still spins up the drives. Helluva annoying. But that's linux for you

[Edvard]

OK, this may be the root of your problem, which it seems was added when everybody went from locate to slocate as default...
(from updatedb.conf man page)

Notes
Unlike the traditional behavior of PRUNEFS and PRUNEPATHS, which excludes the matched directory (or the root of a matched filesystem) from the created database, the matched directory is entered in the created database. This allows e.g. locate /tmp to find the standard temporary directories even though their contents are excluded from the database.

So, even though the contents aren't being indexed, slocate would still like to know that something is there, even though you won't be able to find anything that's on it.

hmmm... That's exactly counter-productive in terms of power saving.

Have you tried mlocate instead? It's a intended as a replacement for locate and slocate and is a (almost) total re-write so there's no (well, maybe a little) recycled code and it performs the indexing differently, which may help the problem if not eliminate.
It's been piled in as the slocate replacement in Fedora and Arch linux (so if you are running either of those, you're already there)
Some discussion of slocate-mlocate-rlocate here.
I'll keep digging...

[f0dder]

Oh, didn't know there was yet another lodate package, heh... gentoo installs slocate by default. I guess slocate does a stat() or similar of the /mnt/raid dir to have it included, this probably wakes up the drives, and then slocate proceeds to ignore the folders below that.

I tried straceing updatedb, but since absolute paths aren't shown, I'd have to actually manually parse the output to see if the lines grepping "raid" are actually /mnt/raid or something else. I'll read th  article you linked, and will consider mlocate - worth a shot anyway.

Thanks so far

[f0dder]

Update:

strace log of updatedb from slocate was around 35 megs (iirc)... the log from mlocate's version is around 18.3 megs, and it seemed to run snappier. Furthermore...

Code

ayanami f0dder # strace -o /tmp/updatedb-strace.log updatedb
ayanami f0dder # hdparm -C /dev/sda /dev/sdb

/dev/sda:
 drive state is:  standby

/dev/sdb:
 drive state is:  standby

[Edvard]

FTW!!


Now I'm off to try mlocate myself...