Salix Forums

Hard drive indicator LED flashes briefly about once every second on my laptop. Have observed this even when booted from an installer CD, though noticed it only with kernel 3.5 and above. Are other users seeing this too?

Does anyone know what might be causing this behavior? Any work-arounds or suggestions for tracing the cause?

Thanks!

Now that you mention it, I notice my hard drive LED flashing at about the same rate.

Could be some deamon is polling your hard drive.

There's iotop in SBo. You could
or use Sourcery, then run it as root.

http://www.youtube.com/watch?v=BsFOOpthVdE

Thanks, iotop sounds like the right diagnostic tool. Wondering if this may be a kernel / driver "feature," because running Single user mode should banish most daemons.

Blinking even occurs when booted from an installer disc, and under PartedMagic (which is built on a recent Slackware base). Happens under the 3.x kernels I've tested, both smp and single-core.

The LED is quiet under Salix 13.37 though, running stock kernel 2.x. May end up compiling a custom 3.x kernel just to check the available options. Will start by checking with iotop though, of course.

See if something happens in your log files, e.g.:
tailf /var/log/messages
tailf /var/log/syslog

Thanks thenktor, the logs are free of any related errors. Using iotop it appears that kjournald is likely the cause. Quacking has turned up some old references about frequent journal updates for ext3 (which I still use), plus suggestions to reduce polling on the hard drive, the CD drive, or both.

Tracing those old sources to the present, I've found some clues in recent updates to this bug report about udisks2 < https://bugs.freedesktop.org/show_bug.cgi?id=26508 >.

Just to gain more understanding, I'm currently checking some related info about udevil at < http://ignorantguru.github.com/udevil/#polling >. So far, results indicate that kernel polling is set to 2 seconds for the hard drive, and disabled for the CD.

I'll update this Topic again when I've got something more concrete to report. Meanwhile I'd still welcome specific feedback!

Hmm. Newer kernels mount ext3 as well as ext4 with write barrier support. Maybe the write barrier is acting up, and causing log files (or something) to be flushed with unnecessary frequency?

Maybe try mounting the ext3 partitions with commit=5,barrier=0 for the old behavior, and see if that gets you anywhere. Just be forewarned that your data is probably not as safe that way.

Thanks, this is the first I've heard about write barrier. Stability and reliability is at least as important to me as performance, so I'll need to research that before making any changes. Is there a reference which you'd recommend?

Meanwhile I've still got a bunch of Firefox tabs open on the subject; a couple of other projects have much higher priority ATM. However, I do remain concerned that my hard drive is being slowly ground to dust

AFAIK modern hard drives do not wear out easily from repeated writes. Gods only know, my machines would all have failed a while ago otherwise; what with all the Linux installs I've done on them...

Re barriers:

http://lwn.net/Articles/283161/ <-- Note that this is a bit dated, LVM honors barriers now.

They force data to be written to the disk in a certain order, so the filesystem doesn't get corrupted if something goes wrong. I may be wrong about them increasing the frequency of writes though.

OK thanks GJones, that rings a bell now that you explain it. Seems that that would actually decrease the number of writes, rather than increase them.

My issue is appears to be unrelated, in that the writes occur like clockwork, once per second. I'll need to reconcile that observation against the configured parameter of 2 seconds. Meanwhile I appreciate your reassurance about the hardiness of modern hard drives

Hardy don't mean priapic

I wouldn't like all those writes any more than you do.