On Mon, Aug 7, 2017 at 7:12 AM, Thomas Wurfbaum <thomas@xxxxxxxxxxxx> wrote: > Now i do a btrfs-find-root, but it runs now since 5 day without a result. > How long should i wait? Or is it already to late to hope? > > mainframe:~ # btrfs-find-root.static /dev/sdb1 > parent transid verify failed on 29376512 wanted 1327723 found 1489835 > parent transid verify failed on 29376512 wanted 1327723 found 1489835 > parent transid verify failed on 29376512 wanted 1327723 found 1489835 > parent transid verify failed on 29376512 wanted 1327723 found 1489835 > Ignoring transid failure > Superblock thinks the generation is 1490226 > Superblock thinks the level is 1 > > The process is still running... I also have a filesystem that has a big difference in wanted and found transid. I my case the wanted is much higher than the found. I also tried to repair it for more than 2 weeks in total, but both progs and kernel fail. I haven't seen that you mounted it just with only ro mount option. I think in your case chances are low, but it worked in my case. I could copy all data (7TB unique non-shared thorugh snapshot or reflink) to a new fs with rsync. Btrfs send and other action done by btrfs progs quite soon failed on 1 or several parent transid inconsistencies. Others on this forum have stated that when there is such a big difference in transid, the fs is simple unrepairable. I must admit that this is the truth in practice. Restore with btrfs-restore I tried once on a other fs that was damaged and at that time the restore gave quite different content for some file compared to a copy of the same file from the fs mouted via the kernel. -- 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
