From: Duncan <1i5t5.duncan@cox.net>
To: linux-btrfs@vger.kernel.org
Subject: Re: unexplainable corruptions 3.17.0
Date: Fri, 17 Oct 2014 11:38:22 +0000 (UTC) [thread overview]
Message-ID: <pan$6eb1$c20caee6$477f612f$2b524b4d@cox.net> (raw)
In-Reply-To: 20141017080202.GA3604@localhost.localdomain
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
next prev parent reply other threads:[~2014-10-17 11:38 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-16 9:17 unexplainable corruptions 3.17.0 Tomasz Torcz
2014-10-17 8:02 ` Liu Bo
2014-10-17 8:10 ` Tomasz Torcz
2014-10-17 8:17 ` Hugo Mills
2014-10-20 14:04 ` Zygo Blaxell
2014-10-20 14:52 ` Rich Freeman
2014-10-17 8:29 ` Liu Bo
2014-10-17 8:54 ` Tomasz Torcz
2014-10-17 12:53 ` Chris Mason
2014-10-17 18:09 ` Rich Freeman
2014-10-18 7:32 ` Chris Samuel
2014-10-19 3:01 ` Chris Samuel
2014-10-20 8:01 ` Marc Dietrich
2014-10-20 9:14 ` Chris Samuel
2014-10-20 19:09 ` Tomasz Torcz
2014-10-17 11:38 ` Duncan [this message]
2014-10-17 15:07 ` Chris Murphy
2014-10-17 17:29 ` Tomasz Torcz
2014-10-17 8:17 ` Marc Dietrich
2014-10-17 15:01 ` Chris Murphy
2014-10-20 19:10 ` Tomasz Torcz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='pan$6eb1$c20caee6$477f612f$2b524b4d@cox.net' \
--to=1i5t5.duncan@cox.net \
--cc=linux-btrfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox