On Wed, Jul 6, 2016 at 11:50 AM, Tomáš Hrdina <thomas....@gmail.com> wrote: > sudo mount -o ro /dev/sdc /shares > mount: wrong fs type, bad option, bad superblock on /dev/sdc, > missing codepage or helper program, or other error > > In some cases useful info is found in syslog - try > dmesg | tail or so. > > > sudo mount -o ro,recovery /dev/sdc /shares > mount: wrong fs type, bad option, bad superblock on /dev/sdc, > missing codepage or helper program, or other error > > In some cases useful info is found in syslog - try > dmesg | tail or so.
[ 275.688919] BTRFS error (device sda): parent transid verify failed on 7008533413888 wanted 70175 found 70132 Looks like the generation is too far back for backup roots. Just for grins, now that all drives are present, what do you get for # btrfs rescue super-recover -v /dev/sda Next I suggest btrfs-image -c9 -t4 and optionally -s to sanitize file names. And also btrfs-debug-tree (this time no -d) redirected to a file. These two files can be big, about the size of the used amount of metadata chunks. These go in the cloud at some point, reference them in a bugzilla.kernel.org bug report by URL. Expect it to be months before a dev looks at it. So now what you want to try to do is use restore. https://btrfs.wiki.kernel.org/index.php/Restore You can use the information from btrfs-find-root to give restore a -t value to try. For example: >Found tree root at 6062830010368 gen 70182 level 1 >Well block 6062434418688(gen: 70181 level: 1) seems good, but >generation/level doesn't match, want gen: 70182 level: 1 >Well block 6062497202176(gen: 69186 level: 0) seems good, but >generation/level doesn't match, want gen: 70182 level: 1 >Well block 6062470332416(gen: 69186 level: 0) seems good, but >generation/level doesn't match, want gen: 70182 level: 1 btrfs restore -t 6062830010368 -v -i /dev/sda <pathtowhereyouwantdatatogo> If that fails totally you can try the next bytenr, for the -t value, 6062434418688. And then the next. Each value down is going backward in time, so it implies some data loss. This is not the end. It's just that it's the safest since no changes to the fs have happened. If you set up some kind of overlay you can be more aggressive like going right for btrfs check --repair and seeing if it can fix things, but without the overlay it's possible to totally break the fs such that even restore won't work. Once you pretty much have everything important off the volume, you can get more aggressive with trying to fix it. OR just blow it away and start over. But I think it's valid to gather as much information about the file system and try to fix it because the autopsy is the main way to make Btrfs better. -- 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
