On Sun, Jun 5, 2016 at 3:31 PM, Christoph Anton Mitterer <calestyo@xxxxxxxxxxxx> wrote: > On Sun, 2016-06-05 at 21:07 +0000, Hugo Mills wrote: >> The problem is that you can't guarantee consistency with >> nodatacow+checksums. If you have nodatacow, then data is overwritten, >> in place. If you do that, then you can't have a fully consistent >> checksum -- there are always race conditions between the checksum and >> the data being written (or the data and the checksum, depending on >> which way round you do it). > > I'm not an expert in the btrfs internals... but I had a pretty long > discussion back then when I brought this up first, and everything that > came out of that - to my understanding - indicated, that it should be > simply possible. > > a) nodatacow just means "no data cow", but not "no meta data cow". > And isn't the checksumming data meda data? So AFAIU, this is itself > anyway COWed. > b) What you refer to above is, AFAIU, that data may be written (not > COWed) and there is of course no guarantee that the written data > matches the checksum (which may e.g. still be the old sum). > => So what? For a file like a VM image constantly being modified, essentially at no time will the csums on disk ever reflect the state of the file. > This anyway only happens in case of crash/etc. and in that case > we anyway have no idea, whether the written not COWed block is > consistent or not, whether we do checksumming or not. If the file is cow'd and checksummed, and there's a crash, there is supposed to be consistency: either the old state or new state for the data is on-disk and the current valid metadata correctly describes which state that data is in. If the file is not cow'd and not checksummed, its consistency is unknown but also ignored, when doing normal reads, balance or scrubs. If the file is not cow'd but were checksummed, there would always be some inconsistency if the file is actively being modified. Only when it's not being modified, and metadata writes for that file are committed to disk and the superblock updated, is there consistency. At any other time, there's inconsistency. So if there's a crash, a balance or scrub or normal read will say the file is corrupt. And the normal way Btrfs deals with corruption on reads from a mounted fs is to complain and it does not pass the corrupt data to user space, instead there's an i/o error. You have to use restore to scrape it off the volume; or alternatively use btrfsck to recompute checksums. Presumably you'd ask for an exception for this kind of file, where it can still be read even though there's a checksum mismatch, can be scrubbed and balanced which will report there's corruption even if there isn't any, and you've gained, insofar as I can tell, a lot of confusion and ambiguity. It's fine you want a change in behavior for Btrfs. But when a developer responds, more than once, about how this is somewhere between difficult and not possible, and you say it should simply be possible, I think that's annoying, bordering on irritating. -- Chris Murphy -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
