Hi Martin,
> On Jan 3, 2016, at 5:06 AM, Martin Steigerwald <mar...@lichtvoll.de> wrote:
>
> Am Sonntag, 3. Januar 2016, 02:02:12 CET schrieb John Center:
>> Hi Martin & Duncan,
>
> Hi John,
>
>> Since I had a backup of my data, I first ran "btrfs check -p" on the
>> unmounted array. It first found 3 parent transid errors:
>>
>> root@ubuntu:~# btrfs check -p /dev/md126p2
>> Checking filesystem on /dev/md126p2
>> UUID: 9b5a6959-7df1-4455-a643-d369487d24aa
>> parent transid verify failed on 97763328 wanted 33736296 found 181864
>> ...
>> Ignoring transid failure
>> parent transid verify failed on 241287168 wanted 33554449 found 17
>> ...
>> Ignoring transid failure
>> parent transid verify failed on 1016217600 wanted 33556071 found 1639
>> ...
>> Ignoring transid failure
>>
>> Then a huge number of bad extent mismatches:
>>
>> bad extent [29360128, 29376512), type mismatch with chunk
>> bad extent [29376512, 29392896), type mismatch with chunk
>> ...
>> bad extent [1039947448320, 1039947464704), type mismatch with chunk
>> bad extent [1039948005376, 1039948021760), type mismatch with chunk
>
> Due to these I recommend you redo the BTRFS filesystem using your backup. See
> the other thread where Duncan explained the situation that this may be a sign
> of a filesystem corruption introduced by a faulty mkfs.btrfs version.
>
> I had this yesterday with one of my BTRFS filesystems and these type mismatch
> things didn´t go away with btrfs check --repair from btrfs-tools 4.3.1.
>
> Also
>
>> Next:
>>
>> Couldn't find free space inode 1
>> checking free space cache [o]
>> parent transid verify failed on 241287168 wanted 33554449 found 17
>> Ignoring transid failure
>> checkingunresolved ref dir 418890 index 0 namelen 15 name umq-onetouch.ko
>> filetype 1 errors 6, no dir index, no inode ref
>> unresolved ref dir 418890 index 8 namelen 15 name ums-onetouch.ko
>> filetype 1 errors 1, no dir item
>
> the further errors and
>
> […]
>> Once it finished, I tried a recovery mount, which went ok. Since I already
>> had a backup of my data, I tried to run btrfs repair:
>> […]
>> Then it got stuck on the same error as before. It appears to be a loop:
>>
>> parent transid verify failed on 1016217600 wanted 33556071 found 1639
>> Ignoring transid failure
>> parent transid verify failed on 1016217600 wanted 33556071 found 1639
>> Ignoring transid failure
>> ...
> […]
>> It's been running this way for over an hour now, never moving on from the
>> same errors & the same couple of files. I'm going to let it run overnight,
>> but I don't have a lot of confidence that it will ever exit this loop. Any
>> recommendations as what I should do next?
>
> is a clear sign to me that it likely is more effective to just redo the
> filesystem from scratch than trying to repair it with the limited
> capabilities
> of current btrfs check command.
>
> So when you have a good backup of your data and want to be confident of a
> sound structure of the filesytem, redo it from scratch with latest
> btrfs-tools
> 4.3.1.
>
> Thats at least my take on this.
>
Yeah, unfortunately I came to the same conclusion. I eventually killed the
repair loop & ran check again with no luck - same errors, no repairs. I'm going
to rebuild it, hopefully next weekend.
Thanks again for your help!
-John--
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
