> >> It seems that metadata CoW makes it impossible to see future data. > >> > >> All btree trees get updated CoW, so no metadata will be overwritten > >> during one transaction. > >> Only super block is overwritten and normally superblock is updated > >> atomically. > >> > >> So either old superblock is still here, all we can see is old tree pointers. > >> Or new superblock is here, all we can see is new tree pointers. > >> And new metadata will never be written into old metadata, there is no > >> way to see future metadata. > >> > > > > Those assumptions could fail if you have unreliable hardware that > > reorders IO across FUA, just drops IO on the floor or a bug in the filesystem > > or block layer. > > Well, if hardware has problem, we can't really do anything to help. > > Maybe that's reason why there are more corruption report for btrfs as > there are more problematic hardware than we thought? > I think we are not understanding each other. dm-log-writes and xfstests are not expected to test unreliable hardware. filesystems are not expected to work properly on unreliable hardware, but they do have sanity checks to try and detect metadata corruptions that could be a result of unreliable hardware/storage stack and put up a big red sign. If we don't wipe block device before log-writes replay, filesystem trips over those sanity checks, because replay to time N-1 without wipe of writes from time N looks awfully similar to flaky hardware/storage stack. > > > > Existence of metadata from the future could look like any of > > the above has happened. > > Btrfs has an extra layer to prevent such problem from happening, each > metadata pointer has its expected generation. > > If one metadata has a mismatch generation with its parent, then kernel > will know something went wrong. > > And in fact, that's the most common failure mode for btrfs (although > most of them is seeing too old metadata), and we're looking into the > problem (but not much progress yet). > Yes, and that is exactly the reason why dm-log-writes has the potential to generate false positive sanity check failures. Granted, I do not know the inner works of btrfs CoW to point out a specific problematic use case. Anyway, we do need to wipe block device before log replay regardless if btrfs needs it or not. Thanks, Amir.
