> On Feb 23, 2017, at 7:15 PM, Hans van Kranenburg
> <[email protected]> wrote:
>
> On 02/23/2017 05:42 PM, Kenneth Bogert wrote:
>>
>>> On Feb 17, 2017, at 1:39 PM, Kenneth Bogert <[email protected]> wrote:
>>>
>>> On Feb 11, 2017, at 12:34 PM, Kenneth Bogert <[email protected]> wrote:
>>>>
>>>> kernel: BTRFS error (device sdb): parent transid verify failed on
>>>> 1721409388544 wanted 19188 found 83121
>>>> [...]
>>
>> Is anyone interested in this problem? If not, I’m planning on rebuilding
>> this filesystem this weekend.
>
> Only this: "kernel: BTRFS error (device sdb): parent transid verify
> failed on 1721409388544 wanted 19188 found 83121" already makes me think
> there's something gone horribly wrong here. And, my guess is that it
> more likely has to do something with hardware than the btrfs program code.
>
> If there's one bit that flipped it might be possible to rescue a
> filesystem manually, but these transid mismatches sound like the
> filesystem is encountering whole blocks of data that should never been
> there in the first place. A whole bunch of writes never ended up on
> disk, while a disk controller assured they would etc.
>
Looking more in-depth into the issue, it appears the subvolume’s node on disk
has been overwritten by an extent leaf node. This explains why a lower transid
is expected:
* btrfs-debug-tree -t 5 /dev/sda5
fs tree key (FS_TREE ROOT_ITEM 0)
leaf 1719148756992 items 88 free space 9279 generation 83701 owner 5
fs uuid 21e09dd8-a54d-49ec-95cb-93fdd94f0c17
chunk uuid 066b3696-4677-4188-a8bf-41430d470fb0
:snip:
item 7 key (256 DIR_ITEM 1613064667) itemoff 15894 itemsize 36
location key (260 ROOT_ITEM -1) type DIR
transid 40 data_len 0 name_len 6
name: Movies
But viewing tree ID 260:
* btrfs-debug-tree -t 260 /dev/sda5
file tree key (260 ROOT_ITEM 0)
leaf 1721409388544 items 173 free space 2306 generation 83121 owner 2
fs uuid 21e09dd8-a54d-49ec-95cb-93fdd94f0c17
chunk uuid 066b3696-4677-4188-a8bf-41430d470fb0
item 0 key (1094746275840 EXTENT_ITEM 20480) itemoff 16246 itemsize 37
extent refs 1 gen 72728 flags DATA
shared data backref parent 1721662996480 count 1
…
This is apparently extents of a file that was open (a VM image) around the time
of the restart. The file was shared over NFS to a Xenserver which was running
it, but the VM was stopped before the restart.
For comparison, the snapshot of the subvolume shows:
* btrfs-debug-tree -t 2127 /dev/sda5
file tree key (2127 ROOT_ITEM 73808)
node 1721460637696 level 1 items 17 free 476 generation 73808 owner 2127
fs uuid 21e09dd8-a54d-49ec-95cb-93fdd94f0c17
chunk uuid 066b3696-4677-4188-a8bf-41430d470fb0
key (256 INODE_ITEM 0) block 1721409421312 (105066493) gen 19188
key (256 DIR_INDEX 27) block 1721415778304 (105066881) gen 19188
key (262 EXTENT_DATA 67211264) block 1719916314624 (104975361) gen 8524
key (286 EXTENT_DATA 803299328) block 1719918362624 (104975486) gen 8524
key (307 EXTENT_DATA 134217728) block 1719372939264 (104942196) gen 8522
key (330 EXTENT_DATA 59768832) block 1719617585152 (104957128) gen 8523
key (356 EXTENT_DATA 320073728) block 1719302012928 (104937867) gen 8522
key (375 DIR_INDEX 4) block 1719919640576 (104975564) gen 8524
key (388 DIR_ITEM 991737881) block 1719869472768 (104972502) gen 8524
key (388 DIR_ITEM 2994564992) block 1719869489152 (104972503) gen 8524
key (388 DIR_INDEX 118) block 1719657889792 (104959588) gen 8523
key (401 INODE_ITEM 0) block 1719743889408 (104964837) gen 8524
key (447 INODE_REF 388) block 1719481237504 (104948806) gen 8523
key (495 INODE_ITEM 0) block 1719422746624 (104945236) gen 8523
key (542 EXTENT_DATA 0) block 1719759962112 (104965818) gen 8524
key (583 EXTENT_DATA 508674048) block 1719431282688 (104945757) gen 8523
key (602 INODE_REF 257) block 1721409404928 (105066492) gen 19188
leaf 1721409421312 items 93 free space 8087 generation 19188 owner 260
fs uuid 21e09dd8-a54d-49ec-95cb-93fdd94f0c17
chunk uuid 066b3696-4677-4188-a8bf-41430d470fb0
item 0 key (256 INODE_ITEM 0) itemoff 16123 itemsize 160
inode generation 40 transid 19188 size 4316 nbytes 0
block group 0 mode 40757 links 1 uid 0 gid 0 rdev 0
sequence 0 flags 0x52(none)
atime 1483029517.350532358 (2016-12-29 08:38:37)
ctime 1483476789.845537792 (2017-01-03 12:53:09)
mtime 1483476789.845537792 (2017-01-03 12:53:09)
otime 1482889255.764891208 (2016-12-27 17:40:55)
item 1 key (256 INODE_REF 256) itemoff 16111 itemsize 12
inode ref index 0 namelen 2 name: ..
There you can see the references to generation 19188.
> The lack of response should probably not be interpreted as "not caring",
> but more like "I really don't know" and just like not mailing a whole
> list with a "me too!" post, people won't mail "I don't know, dude, let's
> go bowling" too much. Or, it might be possible, but only realistically
> done when travelling to you, getting to work with your computer and then
> spending hours to find out what to do.
>
> --
> Hans van Kranenburg
Yes I understand, just hoping for a miracle I guess. With the filesystem in
apparently good condition except for this one issue I was hoping there would be
an easy fix. I’m now rebuilding it slowly, but I figured I would post the last
bit of information I was able to find in the hope it helps someone in the
future.
Kenneth Bogert--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
