Le 22/02/2015 19:28, Jim Murphy a écrit :
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
_______________________________________________
Hi Jim.
As far as I understand, COW means that the whole file is rewritten
everytime you change a single byte in it (or is it only some "extent"?).
That's a real mess when you are continuously appending to files hundreds
of megabytes large, which is the job of a log server.
I have played with the filesystem bits, wanting to try automatic
compression, but not forcing it by default, and, for sure, they can be
set per file. And I doubt it would affect the filesystem's journal. The
NOCOW bit for log files therefore makes sense. If you happen to loose
the log files, you don't loose precious data. Nevertheless I would
rather use a different filesystem for /var for example and keep btrfs
for /usr and /home.
Didier
_______________________________________________
Dng mailing list
[email protected]
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
