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

[Goffredo Baroncelli]

On 2015-04-12 18:06, Lennart Poettering wrote:
> 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?

In my first attempt, I added a switch to the command line.

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

Even if I agree with you about the points above, I am not fully
convinced about changing the NOCOW attribute via tmpfile snippet:
it seems to me an overkill solution..

But I prefer the snippet solution to the old behavior (set the NOCOW attribute
coded in systemd-journald).

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


-- 
gpg @keyserver.linux.it: Goffredo Baroncelli <kreijackATinwind.it>
Key fingerprint BBF5 1610 0B64 DAC6 5F7D  17B2 0EDA 9B37 8B82 E0B5