On Sun, 12.04.15 17:29, Goffredo Baroncelli (kreij...@inwind.it) wrote: > On 2015-04-12 15:12, Lennart Poettering wrote: > > On Sat, 11.04.15 17:07, Zbigniew Jędrzejewski-Szmek (zbys...@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 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel