On Tue, Aug 23, 2016 at 9:19 AM, Malte Westerhoff <mwesterh...@visageimaging.com> wrote: > Hi Chris, > Thanks for the response. > Yes, there is one large raid6 on which there is one LVM physical volume, > which has four logical volumes that each have a btrfs file system. > Only one of them fails to mount, the other three are fine (data2...4). > The RAID itself claims to be clean (see below). > > Output of btrfs-show-super attached. > > btrfs-find-root is running now for 30 minutes. It has produced the following > output so far (but is still running – not sure whether it is hanging or will > eventually terminate). > > quickstore2:~/btrfs-progs # ./btrfs-find-root /dev/mapper/VGBIGRAID6-DATA1 > parent transid verify failed on 7375769206784 wanted 52059 found 52028 > parent transid verify failed on 7375769206784 wanted 52059 found 52028 > parent transid verify failed on 7375769206784 wanted 52059 found 52028 > parent transid verify failed on 7375769206784 wanted 52059 found 52028 > Ignoring transid failure > leaf parent key incorrect 7375769206784 > Superblock thinks the generation is 52059 > Superblock thinks the level is 1
Huh. Well someone who knows more about Btrfs and devices doing the wrong thing will have to speak up. To me this looks like something got the commit order wrong, where the superblock has a more recent generation than any tree generation, as if the metadata for generation 52059 (or even 52058, 52057, or 52056) is not written or not where it's supposed to be, and yet the superblock was updated. >> btrfs-show-super -fa /dev/mapper/VGBIGRAID6-DATA1 Where is this output? -- Chris Murphy -- 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
