[systemd-devel] [PATCH 4/4] Add a new tmpfiles.d snippets to set the NOCOW the journal.

[Lennart Poettering]

On Sun, 12.04.15 17:29, Goffredo Baroncelli (kreijack at inwind.it) wrote:

> On 2015-04-12 15:12, Lennart Poettering wrote:
> > On Sat, 11.04.15 17:07, Zbigniew Jędrzejewski-Szmek (zbyszek at in.waw.pl) wrote:
> > 
> >>>> That's the problem: current functionality works no matter where you
> >>>> store the files, but it's hard to provide the same level of
> >>>> flexibility with the tmpfiles-based solution.
> >>>
> >>> Well, but we never store files outside of /var/log/journal,
> >>> /var/log/journal/%m and /var/log/journal/remote/, do we? 
> >> We can, if instructed to do so. journal-remote can store files wherever.
> >>
> >> Original motivation for this patch was to make the NOCOW on journal files
> >> configurable without too much fuss and without making it an explicit option.
> >> Journal files on btrfs without NOCOW are rather slow, so it seems that most
> >> people will want NOCOW on. But with the proposed patch, people would want
> >> to add the tmpfile snippet to set NOCOW for every location they write too,
> >> which is very visible and requires explicit configuration. Doing this in
> >> journal-file directly was simple, synchronous, and worked everywhere, and
> >> we are replacing this with a more complicated and more brittle scheme.
> >>
> >> Dunno, if you think things are better this way, I'm fine with that,
> >> since both schemes should get the job done. But in the end, adding a
> >> switch in journald.conf seems more in the systemd spirit of doing the right
> >> thing automatically and also less work for both sides...
> > 
> > What about this solution: let's go the tmpfiles way, but also add some
> > code to the journal file writer to log at INFO level an actionable
> > recommendation to turn on the c flag on the directory if we notice
> > that the newly created file doesn't have it, and it is located on
> > btrfs?
> 
> After the work that I done to the tmpfiles, I have to agree with
> Zbyszek. Adding an option to the journal.conf file is the more
> reasonable thing to do.

You mean journald.conf I figure? That's not even read by the remoting
tools, so how is that a solution?

> If we add code that performs only a check in the code of journal, I think that we have the worst solution:
> - journal code is still aware of the NOCOW attribute (== more code complexity)
> - the user had to update/manage a tmpfile.d  manually

Well, again: the nocow thing is a work-around around a design issue
with btrfs, and btrfs is working on correcting that, by adding
auto-defrag to deal better with write patterns such as this.

We should not add new explicit config options for things we already
know *now* that they are a stopgap, and will go away eventually.

With the solution I propose (which is tmpfiles snippet + warning if
non-enabled) we get:

- default behaviour is fast

- default behaviour is easy to override

- specialist users who use the remoting feature and use the thing on a
  non-default directory, are notified about the issue at hand.

- we can easily get rid of it eventually, simply by dropping one
  config line and the generation of a warning. There's no option to
  deprecate then, and keep compat for.

> Let me to suggest the opposite solution:
> - add a switch in the journald.conf file
> - add a check that raise a warning if the NOCOW flag is not-used/used
> 

This does not fix the remoting issue, since journald.conf isn't read
by those tools. Also, it adds a setting we'll eventuall have to get
rid of again. 

Sorry, but I am really against a solution like that. I don't want to
litter the config file with options that are hacks and will go away
one day...

Lennart

-- 
Lennart Poettering, Red Hat