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
::
Re: [Dng] OT - It may be only one f…
