[systemd-devel] [PATCH 2/2] tmpfiles: support globbing for w option
lennart at poettering.net
Tue Sep 11 05:07:04 PDT 2012
On Mon, 10.09.12 22:45, Dave Reisner (d at falconindy.com) wrote:
> On Tue, Sep 11, 2012 at 12:42:24AM +0200, Lennart Poettering wrote:
> > On Mon, 03.09.12 17:13, Dave Reisner (dreisner at archlinux.org) 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 Poettering - Red Hat, Inc.
More information about the systemd-devel