On Mon, 10.09.12 22:45, Dave Reisner ([email protected]) wrote: > > 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.
Oh, humm, I see the problem. But I am not sure this is the right fix for this. I mean, readahead-replay is not ordered before tmpfiles right now (and I am not sure it should be...), so this would still be racy... I am not sure what best to do about this. Kay, Michal, do you have any ideas what we could do for this? > > 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? Well, it is actually intended to be used to write to procfs/sysfs, but not to the entries therein that are device-specific. That means that it's good for writing stuff like /sys/kernel/kexec_crash_size and things like that, but probably not to write stuff that is bound to a specific device that shows up dynamically. Lennart -- Lennart Poettering - Red Hat, Inc. _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
