On 2015-04-12 18:06, Lennart Poettering wrote: > 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?
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 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel