Hi,

First let me make it clear I'm not a fan of either systemd of journald.

I've been watching the "btrfs-linux" mailing list, when the following
subject popped up a few days ago:

Systemd 219 now sets the special FS_NOCOW file flag for its journal
files, possibly breaking RAID repairs.[1]

>From what I can glean from the thread and from "[systemd-devel]
[ANNOUNCE] systemd 219"[2] the concern is for the ability of btrfs to
recover the systemd-journald file if it becomes corrupted. Poettering
seems to be concerned about write speed, the reason for setting
FS_NOCOW it the first place. I wonder it the speed issue is due to the
fact that his team are all developing on systems with SSDs. There was
also the statement that the way FS_NOCOW is set, it only involves the
one file and not the filesystem itself. I didn't see anything that
contradicted that statement, but I could have missed it.

Part of the discussion:

>> btrfs checksumming theoretically allows you to transparently recover
>> after media corruption if filesystem has redundancy (more than one
>> copy of data). Journald checksum will probably detect corruption, but
>> can it repair it?

> No it cannot.

> But btrfs checksumming cannot fix things for you either if you lose
> non-trivial amounts of data. It might be able to fix a few bits of
> errors, but not non-trivial amounts. I mean, that's a simple property
> of error correction codes: the more you want to be able to correct the
> longer must your checksum be. Neither btrfs' nor journald's are
> substantial enough to correct even a sector...

> Lennart

If I have a btrfs mirror and I didn't mess with it by setting FS_NOCOW,
shouldn't I be able to recover the file? I would sure hope so. He
creates this "better" way of logging, then he seems to not even care if
you can use it.

Systemd, to me, is a horror story. The more I read the scarier it gets.
At the very beginning of the 219 Lennart announcement you find this:

> Note that this version is not available in Fedora F22/F23 yet. The
> linker on ARM segfaults. Since the i386 and x86_64 versions built
> fine, I decided to release 219 anyway.

Onward no matter what. Ready or not here systemd comes. We can only
hope that, sooner rather then later, it catches up with them and bites
them, you know where.

[1] The archive for the thread starts here:
http://thread.gmane.org/gmane.comp.file-systems.btrfs/43187

[2] The actual Systemd 219 announcement and LONG discussion can be
found here:
http://lists.freedesktop.org/archives/systemd-devel/2015-February/028447.html

Just another 2¢ in the pot. Has anyone been keeping track of how much
is in the pot? :-)

Jim