On Wed, Feb 18, 2015 at 06:22:38AM +0300, Andrei Borzenkov wrote: > В Wed, 18 Feb 2015 01:14:44 +0100 > Zbigniew Jędrzejewski-Szmek <zbys...@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? No.
Zbyszek _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel