[systemd-devel] [PATCH 4/4] Add a new tmpfiles.d snippets to set the NOCOW the journal.
Lennart Poettering
lennart at poettering.net
Sun Apr 12 06:12:08 PDT 2015
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?
That way, folks who use the tools on non-default directories will at
least be guided to an explanation of the general problem.
Lennart
--
Lennart Poettering, Red Hat
More information about the systemd-devel
mailing list