Bug#779412: block devices loosing state after resume: trigger udev rules to re-apply settings

[Chris]

Am Sat, 28 Feb 2015 09:38:27 +0100
schrieb Michael Biebl <biebl at debian.org>:

> I don't think working around this in udev/systemd is a good idea.

Idealy and in the long run, the kernel drivers should keep state, yes.
But until then, better not to make releases with default configurations
that deliver serious problems (excessive hardware wear, data loss) to
the users. 

I believe before things stadardized around systemd and udev, packages
like hdparm, laptop-mode-tools, pm-utils, acpi-support,
gnome-power-manager, and more, all tried to work around problems with
block devices loosing state. Unfortunately, accumulating a large mess
and interferences resuling in releases with many bugs in this regard.

Now the situation can improve a lot, if we can say packages are safe if
they use udev rules to initialize devices. (As the kernel keeps
state, or systemd centrally triggers a udev change event where this is
not (yet) the case.)

> most of those custom settings aren't applied via udev rules
> anyway.

Which settings were you refering to?
With current versions hdparm, mdadm, etc. all seem to ship udev rules.
And that seems to be the proper way to configure the standard
hot-pluggable systems of today. (leaving aside embedded, non-systemd,
non udev systems)