On Sun, Apr 19, 2015 at 08:41:39PM +0200, Martin Steigerwald wrote: > 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.
Correct. Granularity -- the storage of data is on a block basis (4k), but extent size goes down to individual bytes. I think this means that if you read and then write a single byte and then sync, the block is read into the page cache, the byte is modified, the block is written out (elsewhere, because it's CoW), and then the extents are updated to reference the one modified byte from the new block. I'm not 100% sure on that, though. > > > 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? It's more that if the system crashes or suffers a power outage in that time window, you've got a mismatch that shows EIO even though the data is valid. > > 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. Only if the FS is mounted with nodatacow. :) Hugo. -- Hugo Mills | Jenkins! Chap with the wings there! Five rounds hugo@... carfax.org.uk | rapid! http://carfax.org.uk/ | Brigadier Alistair Lethbridge-Stewart PGP: E2AB1DE4 | Dr Who and the Daemons
signature.asc
Description: Digital signature
