Is hald effecting wear on SSD?

[je33]

I have a 9.0-PRERELEASE system:

tsunami# uname -a
FreeBSD tsunami.lan 9.0-PRERELEASE FreeBSD 9.0-PRERELEASE #0: Fri Dec  2 07:25:19 PST 2011     root@tsunami.lan:/usr/obj/usr/src/sys/TSUNAMI  amd64

Running on a pair of SSDs in zfs root mirror:

tsunami# zpool status
  pool: zroot
 state: ONLINE
 scan: none requested
config:

        NAME        STATE     READ WRITE CKSUM
        zroot       ONLINE       0     0     0
          mirror-0  ONLINE       0     0     0
            ada0p2  ONLINE       0     0     0
            ada2p2  ONLINE       0     0     0

errors: No known data errors

That indicates disk activity at about 1 second intervals that I have traced to hald. When I kill hald, activity stops.
I'm wondering if hald activity writes to disk causing wear on SSDs and what I might do to prevent it if so?

 

[wblock@]

Is it writing, or just polling? Consider removing HAL altogether. It's not required for xorg or xfce any more, don't know about Gnome or KDE.

 

[je33]

I don't know if it is writing or just polling. At this point I'm not sure how to tell one way or the other.

hald not required? I'll have a go at disabling it. I did the standard enable of dbus and hald when my mouse and keyboard would not work when I brought up X.

Should I leave dbus running?

 

[wblock@]

dbus is useful for inter-program communication.

To stop xorg-server from using HAL, turn it off in the ServerLayout section of xorg.conf:

Option "AutoAddDevices" "Off"

x11-servers/xorg-server can also be compiled with the HALD option disabled.

If the mouse has a PS/2 interface, moused(8) might be needed:
/etc/rc.conf

moused_enable="YES"

 

[je33]

Thank you Warren, works perfectly. No more "periodic" disk activity. Is this another conflict with the Handbook?

 

[je33]

To answer my own question: Nope, not in conflict. Upon review, it became clear that I have not visited that section of the handbook in some time. Sorry for that last bit of noise.

 

[wblock@]

If you find mistakes in the Handbook, man pages, or other FreeBSD documentation, submit a PR or at least send a message to the freebsd-doc mailing list. It may not get fixed immediately, but hopefully before the next time you see it.