Liu Bo posted on Fri, 17 Oct 2014 16:02:03 +0800 as excerpted: > On Thu, Oct 16, 2014 at 11:17:26AM +0200, Tomasz Torcz wrote: >> Hi, >> >> Recently I've observed some corruptions to systemd's journal >> files which are somewhat puzzling. This is especially worrying as this >> is btrfs raid1 setup and I expected auto-healing. >> >> System details: 3.17.0-301.fc21.x86_64 >> btrfs: raid1 over 2x dm-crypted 6TB HDDs. >> mount opts: rw,relatime,seclabel,compress=lzo,space_cache >> >> Broken files are in /var/log/journal directory. This directory >> is set NOCOW with chattr, all the files within too. > > Does scrub work for you?
NOCOW implies no checksum, so scrub shouldn't be able to help. Some time back people were reporting problems with corrupted journald journal files, but I've seen no such reports in a long time. This isn't likely much help for your (OP's) use-case, but FWIW, here's what I did with journald. When I switched to systemd here, I set it to volatile storage only, and kept syslog-ng setup for longer term storage. I arranged things so journald's volatile logs had enough room to grow for a normal single session in the /run/log tmpfs. That gives me the nice journald systemd integration, systemctl status reporting the last few log entries for a specific service, etc. But everything still gets passed to syslog-ng (which being on gentoo, I set the systemd USE flag for, so it integrates nicely) as well, and that spits out my normal text logs just as I had it setup to do long before systemd ever came along. It's those that I keep on non-volatile storage so they stick around thru a reboot, and they play nicely with btrfs so I've not had to worry about what journald's binary files might do. Btw, unless you have a need for relatime, noatime is strongly recommended for btrfs. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
