On Tue, Sep 11, 2012 at 12:42:24AM +0200, Lennart Poettering wrote: > On Mon, 03.09.12 17:13, Dave Reisner ([email protected]) wrote: > > > Break out the write logic into a separate function and simply use it as > > a callback to glob_item. > > > > This allows users to consolidate writes to sysfs with multiple similar > > pathnames, e.g. > > > > w /sys/class/block/sd[a-z]/queue/read_ahead_kb - - - - 1024 > > While I am not totally opposed to the patch I think it's the wrong > solution for this problem. > > For this usecase you need to write an udev rule that applies this > settings as the device shows up. This is the only way to make this > race-free and ensure that this setting is also applied to all hard > drives plugged in later. The udev rule would be quite short I guess, but > of course a little bit less obvious, but that's something we could fight > with docs (for example, lennart doing a blog story about how to safely > write values to sysfs -- which coincidentally is already on the TODO > list).
So, to rewind, I currently do indeed have such a udev rule. However, it conflicts with what systemd-readahead does. In this specific case, I want the read_ahead_kb value applied _after_ readahead-replay completes. There's no way for me to do that with a udev rule. tmpfiles runs late enough that I'm not concerned that it inteferes with readahead. > I'd really like to avoid that people end up using tmpfiles for things > like this, so I am leaning vaguely against merging this, but I could > convinced otherwise with another good usecase. Out of curiosity, what _is_ the intended use case if not for writing to procfs and sysfs? > Lennart > > -- > Lennart Poettering - Red Hat, Inc. _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
