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

[Dave Reisner]

On Tue, Sep 11, 2012 at 12:45:25AM +0200, Lennart Poettering wrote:
> On Mon, 03.09.12 23:25, Dave Reisner (d at falconindy.com) wrote:
> 
> > 
> > On Mon, Sep 03, 2012 at 05:13:18PM -0400, Dave Reisner 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
> > > ---
> > > As is, and even without this patch, the example I point out won't work.
> > > I suspect this is a kernel bug, which I've reported:
> > > 
> > > https://bugzilla.kernel.org/show_bug.cgi?id=46981
> > > 
> > > Of course, I'm also happy to provide a workaround here, but I assume that
> > > systemd upstream would rather just have the kernel bug fixed. I haven't
> > > come across any other sysfs nodes (yet) that exhibit this broken behavior.
> > 
> > Just to add to this, is there a particular reason writev was chosen?
> 
> One atomic syscall to write this string without copying any data, that's
> the advantage of the scatter/gather interfaces. Not that it would matter
> much in this case, but I guess it generally is a good habit using
> writev() where appropriate...
> 

One atomic syscall sure -- and that't the point of writev. However, the
backend implementation is still of our concern. It obviously doesn't do
what we want. You actually want that the kernel changes its heuristics
on specific filesystems so that it modifies the behavior that userspace
explicitly requests? Sorry, but this seems entirely wrong to me.

> > This is _always_ going to result in multiple writes, which sysfs won't
> > necessarily play nicely with [0]. 
> 
> Well, that sounds like as if writev was naively implemented in sysfs,
> no?
> 
> Before we work around this in userspace I'd really like to see an
> attempt to get this fixed in the kernel...

Sure, and I've already submitted a patch to at least ignore the invalid
values in this particular case. Jens Axboe has tenatively accepted it
onto his 3.7 branch. I'd still like to see a complete fix.

https://lkml.org/lkml/2012/9/9/29

> Lennart
> 
> -- 
> Lennart Poettering - Red Hat, Inc.