[systemd-devel] [ANNOUNCE] systemd 219

Andrei Borzenkov arvidjaar at gmail.com
Tue Feb 17 19:22:38 PST 2015


В Wed, 18 Feb 2015 01:14:44 +0100
Zbigniew Jędrzejewski-Szmek <zbyszek at in.waw.pl> пишет:

> On Tue, Feb 17, 2015 at 08:05:29PM +0100, Goffredo Baroncelli wrote:
> > Hi Lennart,
> > 
> > On 2015-02-16 23:59, Lennart Poettering wrote:
> > >         * journald now sets the special FS_NOCOW file flag for its
> > >           journal files. This should improve performance on btrfs, by
> > >           avoiding heavy fragmentation when journald's write-pattern
> > >           is used on COW file systems. It degrades btrfs' data
> > >           integrity guarantees for the files to the same levels as for
> > >           ext3/ext4 however. This should be OK though as journald does
> > >           its own data integrity checks and all its objects are
> > >           checksummed on disk. Also, journald should handle btrfs disk
> > >           full events a lot more gracefully now, by processing SIGBUS
> > >           errors, and not relying on fallocate() anymore.
> > 
> > If I read correctly the code, the FS_NOCOW is a temporary workaround, i.e.
> > when the file is closed (or rotated ?) the FS_NOCOW flags is unset again. 
> > It is true ?
> Yes, but you miss the point in general. FS_NOCOW is set during the
> entire time when the file is being written to, which could be months,
> and then it is unset when the file will not be written to anymore. So
> indeed, the file is not protected by btrfs checksums for the majority
> of time, but journald does its own checksumming, so the contents are
> protected in a different way.
> 

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?


> > If so, the time window where a file is un-protect by the checksum is
> > quite small. I was worried not about the corruption detection but about loosing 
> > the ability to recover the file from a good copy (if available) in case of corruption. 
> > But this seems limited only when the file is in use (before the next rotation).
> 
> Zbyszek
> _______________________________________________
> systemd-devel mailing list
> systemd-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel



More information about the systemd-devel mailing list