On Wed, Sep 5, 2012 at 8:04 AM, David Sterba <d...@jikos.cz> wrote: > On Sun, Sep 02, 2012 at 04:43:48AM -0700, Shentino wrote: >> I assume the same results are expected during a scrub as during a normal >> read? > > yes > >> > I've tested this on an 2 disk data/raid1, metadata/raid1 with a running >> > dd over one of the devices continually and using the filesystem. It was >> > slower. >> >> Would I be correct to assume that a core dump on fsck is an automatic >> bug or is using the old 3.3.8 kernel a taint that would invalidate a >> report? Note that this is for the btrfs-progs containing the fsck, >> not the actual kernel side code. > > You're talking about fsck and kernel, I'm not quite sure which one do > you refer to with 'bug'. > > fsck can crash when it finds unexpected data in the tree structures, > but this would mean that it passed through the checksum verification > earlier. This would be a bug, and if it is reproducible on newer kernels > a report on 3.3.x does not disqualify it right away. > > Same holds for kernel, a datastructure inconsistency will most probably > lead to a BUG and subsequent crash. > > david
By this I mean running fsck on a btrfs that was trashed by a 3.3.8 kernel bug. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
