Am Sonntag, 19. April 2015, 18:18:24 schrieb Hugo Mills: > On Sun, Apr 19, 2015 at 07:50:32PM +0200, Martin Steigerwald wrote: > > Am Sonntag, 19. April 2015, 15:18:51 schrieb Hugo Mills: > > > On Sun, Apr 19, 2015 at 05:10:30PM +0200, Martin Steigerwald wrote: > > > > Am Sonntag, 19. April 2015, 22:31:02 schrieb Craig Ringer: > > > > > I'm curious as to whether +C has any effect on BTRFS's > > > > > durability, > > > > > too. > > > > > > > > You will loose the ability to snapshot that directory tree then. > > > > > > > No you won't. > > > > > > The +C attribute still allows snapshotting and reflink copies. > > > > > > However, after the snapshot, writes to either copy will result in > > > that > > > copy being CoWed. (Specifically, writes to an extent of a +C file > > > with > > > more than one reference to the extent will result in a CoW > > > operation, > > > until there is only one reference, and then the writes will not be > > > CoWed again). > > > > > > The practical upshot of this is that every snapshot of, and > > > > > > subsequent writes to, a +C file will introduce fragmentation in the > > > same way that writes to a non-+C file would. > > > > > > You also have a disadvantage with +C that you lose the > > > checksumming > > > > > > features of the FS, and hence the self-healing properties if you're > > > running with btrfs-native RAID. > > > > Thanks for clarifying this Hugo, so chattr +C will make the directory > > cowed again. > > Not quite sure what you mean there. > > If you set +C on a file or directory, there's no CoW operations on > write to any of the affected files, *except* if there's a snapshot, in > which case the file being written to will have *one* CoW operation > before reverting to nodatacow again.
What do you mean by *one* CoW operation, will BTRFS duplicate the whole file to keep it no-cowed? Or, hmmm, I think now I get it: There will be one CoW operation for each write – well, with some granularity, extent? –, but *just* one, cause then the written data is cowed from the snapshot and then can be written again in a no-cowed way. > > And there is not checksumming on the FS at all anymore. Why is the > > later? Why can´t BTRFS checkum nocowed objects or at least the cowed > > ones in the same FS? Cause of atomicity guarentees? > > Atomicity, indeed. You need to be able to update the checksum and > the new data atomically. This is possible when the data can be CoWed, > but if the data is being modified in place, there must be a short > period of time when the two parts are out of sync. And it would be too much effort or too much of a performance penalty to let any checksum check wait till they are in sync again? > Just to make it clear, the lack of checksums is *only* for those > files which are marked +C. The rest of the FS is unaffected. Thanks for that clarification. I read your original wording as if the whole FS was affected. Thanks, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
signature.asc
Description: This is a digitally signed message part.
