Do new desktops continuously access the hard disk?

Z038 · 07-25-2013, 11:42 AM

I could be way off base here, my apologies if so. Could the activity be due to udev doing SMART polling of your hard drives?

Maybe first you could try writing a udev rule to disable it, as suggested in this post in this thread:

Code:

Create a file /etc/udev/rules.d/80-udisks.rules with the following contents:

KERNEL=="sd*[!0-9]", ATTR{removable}=="0", ENV{ID_BUS}=="usb", ENV{DEVTYPE}=="disk", ENV{UDISKS_DISABLE_POLLING}="1"
KERNEL=="sd*[!0-9]", ATTR{removable}=="0", ENV{ID_BUS}=="ata", ENV{DEVTYPE}=="disk", ENV{UDISKS_DISABLE_POLLING}="1"
KERNEL=="sd*[!0-9]", ATTR{removable}=="0", ENV{ID_BUS}=="scsi", ENV{DEVTYPE}=="disk", ENV{ID_VENDOR}=="ATA", ENV{UDISKS_DISABLE_POLLING}="1"

jefro · 07-25-2013, 03:45 PM

At one time I do know that disks would spin down either by command or by an internal drive setting or maybe other setting. The drive setting my be burned on the drive and not able to modify.

If you want to avoid any disk activity then boot to a ram disk, many ways to do that. One could load their compressed image to a ram drive and run it so that only on shutdown would the system copy changes to the drive maybe.

Not sure if any OS change would affect smart fully.

stf92 · 07-25-2013, 03:50 PM

Can the booting to a RAM disk be done modifying some startup script?

stf92 · 07-25-2013, 05:05 PM

I am booting with the 'nohotplug' option which, according to a comment in /etc/rc.d/rc.S, turns off udev. But then I have no mouse in the text consoles. The last message when booting is:

Code:

Starting gpm: /usr/sbin/gpm -m /dev/mouse -t imps2
O0o.oops():[server_tools.c(76)]: Could not open (null).

Another thing I see is that the udevd daemon is loaded anyways.

In /etc/modprobe.d/ I put the file psmouse.conf with this content:

Code:

emoi@server:/etc/modprobe.d$ cat psmouse.conf
##############################################################################
# Do not edit this file; instead, copy it to /etc/modprobe.d/ and edit that
##############################################################################

# PS/2 mouse support:
# The default options when the psmouse module can cause problems with KVM
# switches.  If you experience this, you may want to uncomment the line
# below to use a more basic mouse protocol with the psmouse module:
options psmouse proto=imps

selfprogrammed · 07-26-2013, 03:55 PM

Turning off udev would be a drastic move, and this is not a drastic problem.
I have a Linux 2.4 system that does this same drive LED blinking, so it is not recent to 3.0.
I have a Win98 system where the drive LED blinks like this, so it is hard to blame udev for that.
I have a Linux 2.6 system that does NOT do this, and it has the usual udev rules.

What they both have are customized kernels. It is slightly possible that some kernel drivers are responsible for triggering this, but I think my customized kernels are very similar.
One thing I did do on all my customized kernels is remove all RAID support, and support for unneeded types of disk drivers.
I think I also removed support for hotplugging.

Booting to Ramdisk may hide the activity, but does not cure it.
What is needed is finding the source of the disk activity (even if it is in udev somewhere), then can decide to kill it or live with it.

Have you tried setting power save drive setting to 1 minute and see if the drives will spin down. Perhaps they will in spite of this drive activity.
It might be that it is checking for hot plugging on the unused drive slot, which would not stop the main drive from spinning down.