[systemd-devel] [PATCH 2/2] tmpfiles: support globbing for w option

Dave Reisner d at falconindy.com
Mon Sep 10 19:45:17 PDT 2012

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.

> 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.

More information about the systemd-devel mailing list