Re: Filesystem won't mount (open_ctree failed) or repair (BUG_ON)

2017-06-12 Thread Koen Kooi 
Op 12-06-17 om 01:00 schreef Chris Murphy:
> On Sun, Jun 11, 2017 at 4:13 AM, Koen Kooi  wrote:
>>
>>> Op 11 jun. 2017, om 12:05 heeft Koen Kooi  het 
>>> volgende geschreven:
>>>

 Op 11 jun. 2017, om 06:20 heeft Chris Murphy  het 
 volgende geschreven:

 On Fri, Jun 9, 2017 at 1:57 PM, Hugo Mills  wrote:
>>
>> [..]
>>
 I'd say take a btrfs-image and put it up somewhere and also file a
 bug. The fsck should not crash.
>>>
>>> I’ll create a bugzilla account and file a bug for that.
>>
>> Done: https://bugzilla.kernel.org/show_bug.cgi?id=196031
>>
>> Btrfs-image is still running, will put it online when it has finished. It’s 
>> already 1.2G:
>>
>> koen@beast:~$ du -ms /data/backup/btrfs.img
>> 1205/data/backup/btrfs.img
> 
> Hopefully you're using -s -t4 -c9 but if not you can at least compress
> it after the fact but that takes even longer.

I wasn't using '-s', after I did it and ran it again it shrunk from 14GiB to 
733MiB:

https://dominion.thruhere.net/btrfs.img

xz -9 -e wouldn't only compressed that 14GiB file to 13.99GiB, so I wonder why 
'-s' seems to make such a difference.

regards,

Koen


--
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

Re: Filesystem won't mount (open_ctree failed) or repair (BUG_ON)

2017-06-12 Thread Koen Kooi 
Op 12-06-17 om 00:58 schreef Chris Murphy:

[..]

> Also worth trying btrfs check --mode=lowmem. This doesn't repair but
> is a whole new implementation so it might find the source of the
> problem better than the current fsck.

I ran it under 'catchsegv' to give more data where it segfaults, here's the log:

https://dominion.thruhere.net/btrfsck-lowmem.txt.gz

It's 688K compressed and 16MiB uncompressed.

regards,

Koen


--
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

Re: Filesystem won't mount (open_ctree failed) or repair (BUG_ON)

2017-06-11 Thread Koen Kooi 

> Op 12 jun. 2017, om 00:58 heeft Chris Murphy  het 
> volgende geschreven:
> 
> On Sun, Jun 11, 2017 at 4:05 AM, Koen Kooi  wrote:
>> 
>>> Op 11 jun. 2017, om 06:20 heeft Chris Murphy  het 
>>> volgende geschreven:
>>> 
>>> On Fri, Jun 9, 2017 at 1:57 PM, Hugo Mills  wrote:
 On Fri, Jun 09, 2017 at 09:12:16PM +0200, Koen Kooi wrote:
> Hi,
> 
> Today the kernel got wedged during shutdown (4.11.x tends to do that, 
> haven't
> debugged) and I pressed the reset button. The next boot btrfs won't mount:
> 
> [Fri Jun  9 20:46:07 2017] BTRFS error (device md0): parent transid 
> verify failed on 5840011722752 wanted 170755 found 170832
> [Fri Jun  9 20:46:07 2017] BTRFS error (device md0): parent transid 
> verify failed on 5840011722752 wanted 170755 found 170832
> [Fri Jun  9 20:46:07 2017] BTRFS error (device md0): failed to read block 
> groups: -5
> [Fri Jun  9 20:46:08 2017] BTRFS error (device md0): open_ctree failed
> 
> 
> Superblock shows gen 170816 and the backups have nothing newer. So why
> is it finding generation 170832? It's confused.
> 
> 
>> 
>> 1) kernel 4.10.x -> 4.11.x
>> 2) A journal was added to /dev/md0
>> 3) Force blk-mq mode
> 
> Could be blk-mq + md bug, *shrug* not sure. It's not 4.11 on its own,
> I've been running all of those version since rc1 and haven't had any
> problems, although I also haven't had any forced shutdowns either.
> 
> 
> 
>>> # btrfs rescue super /dev/
>> 
>> All supers are valid, no need to recover
> 
> So it's not like the supers were in the middle of being updated at the
> time of the failure.
> 
> 
>> 
>> 
>>> # btrfs-find-root /dev/
>> 
>> parent transid verify failed on 5840011722752 wanted 170755 found 170832
>> parent transid verify failed on 5840011722752 wanted 170755 found 170832
>> parent transid verify failed on 5840011722752 wanted 170755 found 170832
>> parent transid verify failed on 5840011722752 wanted 170755 found 170832
>> Ignoring transid failure
>> leaf parent key incorrect 5840011722752
>> Superblock thinks the generation is 170816
>> Superblock thinks the level is 1
>> Found tree root at 4355118137344 gen 170816 level 1
>> Well block 4354996797440(gen: 170815 level: 1) seems good, but 
>> generation/level doesn't match, want gen: 170816 level: 1
>> Well block 4354823323648(gen: 170814 level: 1) seems good, but 
>> generation/level doesn't match, want gen: 170816 level: 1
>> Well block 4354691088384(gen: 170813 level: 1) seems good, but 
>> generation/level doesn't match, want gen: 170816 level: 1
> 
> Try mounting with -o ro,usebackuproot and report back on dmesg. At
> least that's faster to make a backup than scraping with btrfs restore.
> Although I think what you have should be possible to scrape with btrfs
> restore if ro,usebackuproot doesn't work.


root@beast:~# mount /dev/md0 /data/media/ -o ro,usebackuproot

[Mon Jun 12 07:15:47 2017] BTRFS info (device md0): trying to use backup root 
at mount time
[Mon Jun 12 07:15:47 2017] BTRFS info (device md0): using free space tree
[Mon Jun 12 07:15:47 2017] BTRFS info (device md0): has skinny extents
[Mon Jun 12 07:15:48 2017] BTRFS error (device md0): parent transid verify 
failed on 5840011722752 wanted 170755 found 170832
[Mon Jun 12 07:15:48 2017] BTRFS error (device md0): parent transid verify 
failed on 5840011722752 wanted 170755 found 170832
[Mon Jun 12 07:15:48 2017] BTRFS error (device md0): failed to read block 
groups: -5
[Mon Jun 12 07:15:48 2017] BTRFS error (device md0): open_ctree failed

> 
> Also worth trying btrfs check --mode=lowmem. This doesn't repair but
> is a whole new implementation so it might find the source of the
> problem better than the current fsck. There are patches that can be
> applied to fix some of the found problems but of course it could make
> things worse.

That runs for a few hours and segfaults at the end, I’ll run it again and post 
the log.

regards,

Koen--
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

Re: Filesystem won't mount (open_ctree failed) or repair (BUG_ON)

2017-06-11 Thread Chris Murphy 
On Sun, Jun 11, 2017 at 4:13 AM, Koen Kooi  wrote:
>
>> Op 11 jun. 2017, om 12:05 heeft Koen Kooi  het 
>> volgende geschreven:
>>
>>>
>>> Op 11 jun. 2017, om 06:20 heeft Chris Murphy  het 
>>> volgende geschreven:
>>>
>>> On Fri, Jun 9, 2017 at 1:57 PM, Hugo Mills  wrote:
>
> [..]
>
>>> I'd say take a btrfs-image and put it up somewhere and also file a
>>> bug. The fsck should not crash.
>>
>> I’ll create a bugzilla account and file a bug for that.
>
> Done: https://bugzilla.kernel.org/show_bug.cgi?id=196031
>
> Btrfs-image is still running, will put it online when it has finished. It’s 
> already 1.2G:
>
> koen@beast:~$ du -ms /data/backup/btrfs.img
> 1205/data/backup/btrfs.img

Hopefully you're using -s -t4 -c9 but if not you can at least compress
it after the fact but that takes even longer.



-- 
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

Re: Filesystem won't mount (open_ctree failed) or repair (BUG_ON)

2017-06-11 Thread Chris Murphy 
On Sun, Jun 11, 2017 at 4:05 AM, Koen Kooi  wrote:
>
>> Op 11 jun. 2017, om 06:20 heeft Chris Murphy  het 
>> volgende geschreven:
>>
>> On Fri, Jun 9, 2017 at 1:57 PM, Hugo Mills  wrote:
>>> On Fri, Jun 09, 2017 at 09:12:16PM +0200, Koen Kooi wrote:
 Hi,

 Today the kernel got wedged during shutdown (4.11.x tends to do that, 
 haven't
 debugged) and I pressed the reset button. The next boot btrfs won't mount:

 [Fri Jun  9 20:46:07 2017] BTRFS error (device md0): parent transid verify 
 failed on 5840011722752 wanted 170755 found 170832
 [Fri Jun  9 20:46:07 2017] BTRFS error (device md0): parent transid verify 
 failed on 5840011722752 wanted 170755 found 170832
 [Fri Jun  9 20:46:07 2017] BTRFS error (device md0): failed to read block 
 groups: -5
 [Fri Jun  9 20:46:08 2017] BTRFS error (device md0): open_ctree failed


Superblock shows gen 170816 and the backups have nothing newer. So why
is it finding generation 170832? It's confused.


>
> 1) kernel 4.10.x -> 4.11.x
> 2) A journal was added to /dev/md0
> 3) Force blk-mq mode

Could be blk-mq + md bug, *shrug* not sure. It's not 4.11 on its own,
I've been running all of those version since rc1 and haven't had any
problems, although I also haven't had any forced shutdowns either.



>> # btrfs rescue super /dev/
>
> All supers are valid, no need to recover

So it's not like the supers were in the middle of being updated at the
time of the failure.


>
>
>> # btrfs-find-root /dev/
>
> parent transid verify failed on 5840011722752 wanted 170755 found 170832
> parent transid verify failed on 5840011722752 wanted 170755 found 170832
> parent transid verify failed on 5840011722752 wanted 170755 found 170832
> parent transid verify failed on 5840011722752 wanted 170755 found 170832
> Ignoring transid failure
> leaf parent key incorrect 5840011722752
> Superblock thinks the generation is 170816
> Superblock thinks the level is 1
> Found tree root at 4355118137344 gen 170816 level 1
> Well block 4354996797440(gen: 170815 level: 1) seems good, but 
> generation/level doesn't match, want gen: 170816 level: 1
> Well block 4354823323648(gen: 170814 level: 1) seems good, but 
> generation/level doesn't match, want gen: 170816 level: 1
> Well block 4354691088384(gen: 170813 level: 1) seems good, but 
> generation/level doesn't match, want gen: 170816 level: 1

Try mounting with -o ro,usebackuproot and report back on dmesg. At
least that's faster to make a backup than scraping with btrfs restore.
Although I think what you have should be possible to scrape with btrfs
restore if ro,usebackuproot doesn't work.

Also worth trying btrfs check --mode=lowmem. This doesn't repair but
is a whole new implementation so it might find the source of the
problem better than the current fsck. There are patches that can be
applied to fix some of the found problems but of course it could make
things worse.



-- 
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

Re: Filesystem won't mount (open_ctree failed) or repair (BUG_ON)

2017-06-11 Thread Koen Kooi 

> Op 11 jun. 2017, om 12:05 heeft Koen Kooi  het 
> volgende geschreven:
> 
>> 
>> Op 11 jun. 2017, om 06:20 heeft Chris Murphy  het 
>> volgende geschreven:
>> 
>> On Fri, Jun 9, 2017 at 1:57 PM, Hugo Mills  wrote:

[..]

>> I'd say take a btrfs-image and put it up somewhere and also file a
>> bug. The fsck should not crash.
> 
> I’ll create a bugzilla account and file a bug for that.

Done: https://bugzilla.kernel.org/show_bug.cgi?id=196031

Btrfs-image is still running, will put it online when it has finished. It’s 
already 1.2G:

koen@beast:~$ du -ms /data/backup/btrfs.img 
1205/data/backup/btrfs.img

regards,

Koen--
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

Re: Filesystem won't mount (open_ctree failed) or repair (BUG_ON)

2017-06-11 Thread Koen Kooi 

> Op 11 jun. 2017, om 06:20 heeft Chris Murphy  het 
> volgende geschreven:
> 
> On Fri, Jun 9, 2017 at 1:57 PM, Hugo Mills  wrote:
>> On Fri, Jun 09, 2017 at 09:12:16PM +0200, Koen Kooi wrote:
>>> Hi,
>>> 
>>> Today the kernel got wedged during shutdown (4.11.x tends to do that, 
>>> haven't
>>> debugged) and I pressed the reset button. The next boot btrfs won't mount:
>>> 
>>> [Fri Jun  9 20:46:07 2017] BTRFS error (device md0): parent transid verify 
>>> failed on 5840011722752 wanted 170755 found 170832
>>> [Fri Jun  9 20:46:07 2017] BTRFS error (device md0): parent transid verify 
>>> failed on 5840011722752 wanted 170755 found 170832
>>> [Fri Jun  9 20:46:07 2017] BTRFS error (device md0): failed to read block 
>>> groups: -5
>>> [Fri Jun  9 20:46:08 2017] BTRFS error (device md0): open_ctree failed
>> 
>>   With a transid failure on mount, about the only thing that's likely
>> to work is mounting with -o usebackuproot. If that doesn't work, then
>> a rebuild of the FS is almost certainly needed.
> 
> Weird that it wants almost 80 generations back from what's found.
> Sounds like betrayal somewhere…

The issue I have with 4.11.x is that after a few days “kworker” starts to take 
100% cpu which only a reboot will fix. I’m not sure what caused this btrfs 
corruption, since multiple things changed: 

1) kernel 4.10.x -> 4.11.x
2) A journal was added to /dev/md0
3) Force blk-mq mode

4.12rc would hard lock, but rc4 looks a lot better, it’s still up after 2 days, 
but then again, /dev/md0 hasn’t been used :)

I now fully understand what “RAID is not a backup” is all about :/

> I'd say take a btrfs-image and put it up somewhere and also file a
> bug. The fsck should not crash.

I’ll create a bugzilla account and file a bug for that.

> 
> What are these showing?

Output attached inline, see below.

> # btrfs insp dump-s -f /dev/

superblock: bytenr=65536, device=/dev/md0
-
csum_type   0 (crc32c)
csum_size   4
csum0x0fb18762 [match]
bytenr  65536
flags   0x1
( WRITTEN )
magic   _BHRfS_M [match]
fside00f9fd0-8b57-43c1-8d8b-1c27a40aef28
label   
generation  170816
root4355118137344
sys_array_size  129
chunk_root_generation   170426
root_level  1
chunk_root  29519205384192
chunk_root_level1
log_root0
log_root_transid0
log_root_level  0
total_bytes 20003257057280
bytes_used  14730770751488
sectorsize  4096
nodesize16384
leafsize16384
stripesize  4096
root_dir6
num_devices 1
compat_flags0x0
compat_ro_flags 0x3
( FREE_SPACE_TREE |
  FREE_SPACE_TREE_VALID )
incompat_flags  0x169
( MIXED_BACKREF |
  COMPRESS_LZO |
  BIG_METADATA |
  EXTENDED_IREF |
  SKINNY_METADATA )
cache_generation74920
uuid_tree_generation170816
dev_item.uuid   acbd8ddf-5bf8-4b08-9cdd-a750c2cb7bc6
dev_item.fsid   e00f9fd0-8b57-43c1-8d8b-1c27a40aef28 [match]
dev_item.type   0
dev_item.total_bytes20003257057280
dev_item.bytes_used 14871399759872
dev_item.io_align   4096
dev_item.io_width   4096
dev_item.sector_size4096
dev_item.devid  1
dev_item.dev_group  0
dev_item.seek_speed 0
dev_item.bandwidth  0
dev_item.generation 0
sys_chunk_array[2048]:
item 0 key (FIRST_CHUNK_TREE CHUNK_ITEM 29519205367808)
length 33554432 owner 2 stripe_len 65536 type SYSTEM|DUP
io_align 65536 io_width 65536 sector_size 4096
num_stripes 2 sub_stripes 1
stripe 0 devid 1 offset 288874299392
dev_uuid acbd8ddf-5bf8-4b08-9cdd-a750c2cb7bc6
stripe 1 devid 1 offset 288907853824
dev_uuid acbd8ddf-5bf8-4b08-9cdd-a750c2cb7bc6
backup_roots[4]:
backup 0:
backup_tree_root:   4354691088384   gen: 170813 level: 1
backup_chunk_root:  29519205384192  gen: 170426 level: 1
backup_extent_root: 4354711486464   gen: 170814 level: 2
backup_fs_root: 1667614900224   gen: 110362 level: 0
backup_dev_root:2324468563968   gen: 170426 level: 1
backup_csum_root:   3920799973376   gen: 170813 level: 3
backup_total_bytes: 20003257057280
backup_bytes_used:  14730770980864
backup_num_devices: 1

backup

Re: Filesystem won't mount (open_ctree failed) or repair (BUG_ON)

2017-06-10 Thread Chris Murphy 
On Fri, Jun 9, 2017 at 1:57 PM, Hugo Mills  wrote:
> On Fri, Jun 09, 2017 at 09:12:16PM +0200, Koen Kooi wrote:
>> Hi,
>>
>> Today the kernel got wedged during shutdown (4.11.x tends to do that, haven't
>> debugged) and I pressed the reset button. The next boot btrfs won't mount:
>>
>> [Fri Jun  9 20:46:07 2017] BTRFS error (device md0): parent transid verify 
>> failed on 5840011722752 wanted 170755 found 170832
>> [Fri Jun  9 20:46:07 2017] BTRFS error (device md0): parent transid verify 
>> failed on 5840011722752 wanted 170755 found 170832
>> [Fri Jun  9 20:46:07 2017] BTRFS error (device md0): failed to read block 
>> groups: -5
>> [Fri Jun  9 20:46:08 2017] BTRFS error (device md0): open_ctree failed
>
>With a transid failure on mount, about the only thing that's likely
> to work is mounting with -o usebackuproot. If that doesn't work, then
> a rebuild of the FS is almost certainly needed.

Weird that it wants almost 80 generations back from what's found.
Sounds like betrayal somewhere...

I'd say take a btrfs-image and put it up somewhere and also file a
bug. The fsck should not crash.

What are these showing?
# btrfs insp dump-s -f /dev/
# btrfs rescue super /dev/
# btrfs-find-root /dev/



-- 
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

Re: Filesystem won't mount (open_ctree failed) or repair (BUG_ON)

2017-06-09 Thread Koen Kooi 
Op 09-06-17 om 21:57 schreef Hugo Mills:
> On Fri, Jun 09, 2017 at 09:12:16PM +0200, Koen Kooi wrote:
>> Hi,
>>
>> Today the kernel got wedged during shutdown (4.11.x tends to do that, haven't
>> debugged) and I pressed the reset button. The next boot btrfs won't mount:
>>
>> [Fri Jun  9 20:46:07 2017] BTRFS error (device md0): parent transid verify 
>> failed on 5840011722752 wanted 170755 found 170832
>> [Fri Jun  9 20:46:07 2017] BTRFS error (device md0): parent transid verify 
>> failed on 5840011722752 wanted 170755 found 170832
>> [Fri Jun  9 20:46:07 2017] BTRFS error (device md0): failed to read block 
>> groups: -5
>> [Fri Jun  9 20:46:08 2017] BTRFS error (device md0): open_ctree failed
> 
>With a transid failure on mount, about the only thing that's likely
> to work is mounting with -o usebackuproot. If that doesn't work, then
> a rebuild of the FS is almost certainly needed.

Hrm, that is also a no-go:

# mount /dev/md0 /media/data/  -o usebackuproot

[  740.294141] BTRFS info (device md0): trying to use backup root at mount time
[  740.294145] BTRFS info (device md0): using free space tree
[  740.294146] BTRFS info (device md0): has skinny extents
[  754.248228] BTRFS error (device md0): parent transid verify failed on 
5840011722752 wanted 170755 found 170832
[  754.449435] BTRFS error (device md0): parent transid verify failed on 
5840011722752 wanted 170755 found 170832
[  754.449527] BTRFS error (device md0): failed to read block groups: -5
[  754.609960] BTRFS error (device md0): open_ctree failed

So, any more suggestions of things to try?

regards,

Koen

> 
>Hugo.
> 
>> I tried repair, but that didn't work either:
>>
>> # btrfsck --repair /dev/md0
>> enabling repair mode
>> couldn't open RDWR because of unsupported option features (3).
>> ERROR: cannot open file system
>> enabling repair mode
>>
>> Googling around it was suggested clearing the v2 space cache:
>>
>> # btrfsck --mode=lowmem --clear-space-cache v2 /dev/md0
>> parent transid verify failed on 5840011722752 wanted 170755 found 170832
>> parent transid verify failed on 5840011722752 wanted 170755 found 170832
>> parent transid verify failed on 5840011722752 wanted 170755 found 170832
>> parent transid verify failed on 5840011722752 wanted 170755 found 170832
>> Ignoring transid failure
>> leaf parent key incorrect 5840011722752
>> parent transid verify failed on 5367057465344 wanted 170755 found 170828
>> parent transid verify failed on 5367057465344 wanted 170755 found 170828
>> parent transid verify failed on 5367057465344 wanted 170755 found 170828
>> parent transid verify failed on 5367057465344 wanted 170755 found 170828
>> Ignoring transid failure
>> leaf parent key incorrect 72105984
>> btrfs unable to find ref byte nr 4628577484800 parent 0 root 10  owner 0 
>> offset 1
>> parent transid verify failed on 5366993256448 wanted 170755 found 170827
>> parent transid verify failed on 5366993256448 wanted 170755 found 170827
>> parent transid verify failed on 5366993256448 wanted 170755 found 170827
>> parent transid verify failed on 5366993256448 wanted 170755 found 170827
>> Ignoring transid failure
>> leaf parent key incorrect 41287680
>> ERROR: failed to clear free space cache v2: -1
>> transaction.h:41: btrfs_start_transaction: BUG_ON `root->commit_root` 
>> triggered, value 22938400
>> btrfs check[0x411674]
>> btrfs check(close_ctree_fs_info+0x125)[0x41368c]
>> btrfs check(cmd_check+0x36d8)[0x45e8e8]
>> btrfs check(main+0x15d)[0x40ac5c]
>> /lib/libc.so.6(__libc_start_main+0xf0)[0x7f9b4cb060d0]
>> btrfs check[0x40a729]
>> Clear free space cache v2
>>
>> The underlying md0 (raid6) doesn't report any errors, trying different 
>> kernels makes no difference, 4.10.17, 4.11.4 and 4.12.0-rc4 all give the 
>> same errors. Everything above was
>> done with btrfs-progs 4.11.
>>
>> Any hints on how I can fix the errors in the filesystem? I don't mind 
>> loosing todays changes, but I would like to keep all the older data :)
>>
>> regards,
>>
>> Koen
>>
> 


--
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

Re: Filesystem won't mount (open_ctree failed) or repair (BUG_ON)

2017-06-09 Thread Hugo Mills 
On Fri, Jun 09, 2017 at 09:12:16PM +0200, Koen Kooi wrote:
> Hi,
> 
> Today the kernel got wedged during shutdown (4.11.x tends to do that, haven't
> debugged) and I pressed the reset button. The next boot btrfs won't mount:
> 
> [Fri Jun  9 20:46:07 2017] BTRFS error (device md0): parent transid verify 
> failed on 5840011722752 wanted 170755 found 170832
> [Fri Jun  9 20:46:07 2017] BTRFS error (device md0): parent transid verify 
> failed on 5840011722752 wanted 170755 found 170832
> [Fri Jun  9 20:46:07 2017] BTRFS error (device md0): failed to read block 
> groups: -5
> [Fri Jun  9 20:46:08 2017] BTRFS error (device md0): open_ctree failed

   With a transid failure on mount, about the only thing that's likely
to work is mounting with -o usebackuproot. If that doesn't work, then
a rebuild of the FS is almost certainly needed.

   Hugo.

> I tried repair, but that didn't work either:
> 
> # btrfsck --repair /dev/md0
> enabling repair mode
> couldn't open RDWR because of unsupported option features (3).
> ERROR: cannot open file system
> enabling repair mode
> 
> Googling around it was suggested clearing the v2 space cache:
> 
> # btrfsck --mode=lowmem --clear-space-cache v2 /dev/md0
> parent transid verify failed on 5840011722752 wanted 170755 found 170832
> parent transid verify failed on 5840011722752 wanted 170755 found 170832
> parent transid verify failed on 5840011722752 wanted 170755 found 170832
> parent transid verify failed on 5840011722752 wanted 170755 found 170832
> Ignoring transid failure
> leaf parent key incorrect 5840011722752
> parent transid verify failed on 5367057465344 wanted 170755 found 170828
> parent transid verify failed on 5367057465344 wanted 170755 found 170828
> parent transid verify failed on 5367057465344 wanted 170755 found 170828
> parent transid verify failed on 5367057465344 wanted 170755 found 170828
> Ignoring transid failure
> leaf parent key incorrect 72105984
> btrfs unable to find ref byte nr 4628577484800 parent 0 root 10  owner 0 
> offset 1
> parent transid verify failed on 5366993256448 wanted 170755 found 170827
> parent transid verify failed on 5366993256448 wanted 170755 found 170827
> parent transid verify failed on 5366993256448 wanted 170755 found 170827
> parent transid verify failed on 5366993256448 wanted 170755 found 170827
> Ignoring transid failure
> leaf parent key incorrect 41287680
> ERROR: failed to clear free space cache v2: -1
> transaction.h:41: btrfs_start_transaction: BUG_ON `root->commit_root` 
> triggered, value 22938400
> btrfs check[0x411674]
> btrfs check(close_ctree_fs_info+0x125)[0x41368c]
> btrfs check(cmd_check+0x36d8)[0x45e8e8]
> btrfs check(main+0x15d)[0x40ac5c]
> /lib/libc.so.6(__libc_start_main+0xf0)[0x7f9b4cb060d0]
> btrfs check[0x40a729]
> Clear free space cache v2
> 
> The underlying md0 (raid6) doesn't report any errors, trying different 
> kernels makes no difference, 4.10.17, 4.11.4 and 4.12.0-rc4 all give the same 
> errors. Everything above was
> done with btrfs-progs 4.11.
> 
> Any hints on how I can fix the errors in the filesystem? I don't mind loosing 
> todays changes, but I would like to keep all the older data :)
> 
> regards,
> 
> Koen
> 

-- 
Hugo Mills | Close enough for government work.
hugo@... carfax.org.uk |
http://carfax.org.uk/  |
PGP: E2AB1DE4  |


signature.asc
Description: Digital signature