* Mount failure with 5.2.7 but mounts with 5.1.4
@ 2019-08-10 15:54 Peter Chant
2019-08-10 17:53 ` Nikolay Borisov
2019-08-11 0:13 ` Qu Wenruo
0 siblings, 2 replies; 7+ messages in thread
From: Peter Chant @ 2019-08-10 15:54 UTC (permalink / raw)
To: Btrfs BTRFS
I attempted update an i5 machine today with kernel 5.2.7. Unfortunately
I could not mount the file system. However, reverting the kernel back
to 5.1.4 allowed it to mount with no issue.
This issue is not critical to me, machine boots with older kernel, I
have a backup and the machine is only lightly used anyway. However, I
wonder whether this info is useful to anyone?
I have a spare ext4 root partition on the hard drive of the affected
machine, so I booted to that, with 5.2.7, and got the following behaviour.
dmesg:
[ 55.139154] BTRFS: device fsid 5128caf4-b518-4b65-ae46-b5505281e500
devid 1 transid 66785 /dev/sda4
[ 55.139623] BTRFS info (device sda4): disk space caching is enabled
[ 55.813959] BTRFS critical (device sda4): corrupt leaf: root=5
block=38884884480 slot=1 ino=45745394, invalid inode generation: has
18446744073709551492 expect [0, 66786]
[ 55.817296] BTRFS error (device sda4): block=38884884480 read time
tree block corruption detected
[ 55.817342] BTRFS warning (device sda4): failed to read fs tree: -5
[ 55.834802] BTRFS error (device sda4): open_ctree failed
/var/log/messages:
Aug 10 11:59:05 retreat dbus[903]: [system] Activating service
name='org.freedesktop.PolicyKit1' (using servicehelper)
Aug 10 11:59:05 retreat polkitd[975]: started daemon version 0.105 using
authority implementation `local' version `0.105'
Aug 10 11:59:05 retreat dbus[903]: [system] Successfully activated
service 'org.freedesktop.PolicyKit1'
Aug 10 11:59:31 retreat kernel: [ 55.139154] BTRFS: device fsid
5128caf4-b518-4b65-ae46-b5505281e500 devid 1 transid 66785 /dev/sda4
Aug 10 11:59:31 retreat kernel: [ 55.139623] BTRFS info (device sda4):
disk space caching is enabled
uname -a:
Linux retreat 5.2.7 #1 SMP Wed Aug 7 23:53:42 BST 2019 x86_64 Intel(R)
Core(TM) i5-4430 CPU @ 3.00GHz GenuineIntel GNU/Linux
Rebooting with 5.1.4 showed no problems.
A very similar kernel, with AMD rather than Intel processor options, is
running on the Ryzen machine I am typing this on. I did have my hdd
file system seem to hang, but not sure if that is related.
I have not tried the intel kernel on my laptop, but the laptop is a lot
older, as it is a core2duo.
Seems a bit odd to me that 5.2.7 should show such an issue but 5.1.4 be
OK with it.
Pete
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Mount failure with 5.2.7 but mounts with 5.1.4
2019-08-10 15:54 Mount failure with 5.2.7 but mounts with 5.1.4 Peter Chant
@ 2019-08-10 17:53 ` Nikolay Borisov
2019-08-10 18:19 ` Pete
2019-08-11 0:13 ` Qu Wenruo
1 sibling, 1 reply; 7+ messages in thread
From: Nikolay Borisov @ 2019-08-10 17:53 UTC (permalink / raw)
To: Peter Chant, Btrfs BTRFS
On 10.08.19 г. 18:54 ч., Peter Chant wrote:
> I attempted update an i5 machine today with kernel 5.2.7. Unfortunately
> I could not mount the file system. However, reverting the kernel back
> to 5.1.4 allowed it to mount with no issue.
>
> This issue is not critical to me, machine boots with older kernel, I
> have a backup and the machine is only lightly used anyway. However, I
> wonder whether this info is useful to anyone?
>
> I have a spare ext4 root partition on the hard drive of the affected
> machine, so I booted to that, with 5.2.7, and got the following behaviour.
>
> dmesg:
>
> [ 55.139154] BTRFS: device fsid 5128caf4-b518-4b65-ae46-b5505281e500
> devid 1 transid 66785 /dev/sda4
> [ 55.139623] BTRFS info (device sda4): disk space caching is enabled
> [ 55.813959] BTRFS critical (device sda4): corrupt leaf: root=5
> block=38884884480 slot=1 ino=45745394, invalid inode generation: has
> 18446744073709551492 expect [0, 66786]
It seems you have triggered one of the enhanced checks. Looks like the
generation (i.e transaction id) of inode 45745394 seems to be larger
than the inode of the super block. This doesn't make sense. Looking at
the number of this inode it seems to have overflown.
A possible work around will be to copy the file that this inode
describes and delete the original(corrupted one) then your fs should be
mountable on the newer kernel.
> [ 55.817296] BTRFS error (device sda4): block=38884884480 read time
> tree block corruption detected
> [ 55.817342] BTRFS warning (device sda4): failed to read fs tree: -5
> [ 55.834802] BTRFS error (device sda4): open_ctree failed
>
> /var/log/messages:
> Aug 10 11:59:05 retreat dbus[903]: [system] Activating service
> name='org.freedesktop.PolicyKit1' (using servicehelper)
> Aug 10 11:59:05 retreat polkitd[975]: started daemon version 0.105 using
> authority implementation `local' version `0.105'
> Aug 10 11:59:05 retreat dbus[903]: [system] Successfully activated
> service 'org.freedesktop.PolicyKit1'
> Aug 10 11:59:31 retreat kernel: [ 55.139154] BTRFS: device fsid
> 5128caf4-b518-4b65-ae46-b5505281e500 devid 1 transid 66785 /dev/sda4
> Aug 10 11:59:31 retreat kernel: [ 55.139623] BTRFS info (device sda4):
> disk space caching is enabled
>
> uname -a:
> Linux retreat 5.2.7 #1 SMP Wed Aug 7 23:53:42 BST 2019 x86_64 Intel(R)
> Core(TM) i5-4430 CPU @ 3.00GHz GenuineIntel GNU/Linux
>
> Rebooting with 5.1.4 showed no problems.
>
>
> A very similar kernel, with AMD rather than Intel processor options, is
> running on the Ryzen machine I am typing this on. I did have my hdd
> file system seem to hang, but not sure if that is related.
>
> I have not tried the intel kernel on my laptop, but the laptop is a lot
> older, as it is a core2duo.
>
> Seems a bit odd to me that 5.2.7 should show such an issue but 5.1.4 be
> OK with it.
>
> Pete
>
>
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Mount failure with 5.2.7 but mounts with 5.1.4
2019-08-10 17:53 ` Nikolay Borisov
@ 2019-08-10 18:19 ` Pete
0 siblings, 0 replies; 7+ messages in thread
From: Pete @ 2019-08-10 18:19 UTC (permalink / raw)
To: Nikolay Borisov, Btrfs BTRFS
On 8/10/19 6:53 PM, Nikolay Borisov wrote:
> It seems you have triggered one of the enhanced checks. Looks like the
> generation (i.e transaction id) of inode 45745394 seems to be larger
> than the inode of the super block. This doesn't make sense. Looking at
> the number of this inode it seems to have overflown.
>
OK, I'm not a dev so that is rather lost on me...
>
> A possible work around will be to copy the file that this inode
> describes and delete the original(corrupted one) then your fs should be
> mountable on the newer kernel.
Thanks. I've searched how to find a file by inode number, I can try
that. I presume I'll need to do this in 5.1.4 since 5.2.7 does not mount.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Mount failure with 5.2.7 but mounts with 5.1.4
2019-08-10 15:54 Mount failure with 5.2.7 but mounts with 5.1.4 Peter Chant
2019-08-10 17:53 ` Nikolay Borisov
@ 2019-08-11 0:13 ` Qu Wenruo
2019-08-11 16:23 ` Pete
1 sibling, 1 reply; 7+ messages in thread
From: Qu Wenruo @ 2019-08-11 0:13 UTC (permalink / raw)
To: Peter Chant, Btrfs BTRFS
[-- Attachment #1.1: Type: text/plain, Size: 2840 bytes --]
On 2019/8/10 下午11:54, Peter Chant wrote:
> I attempted update an i5 machine today with kernel 5.2.7. Unfortunately
> I could not mount the file system. However, reverting the kernel back
> to 5.1.4 allowed it to mount with no issue.
>
> This issue is not critical to me, machine boots with older kernel, I
> have a backup and the machine is only lightly used anyway. However, I
> wonder whether this info is useful to anyone?
>
> I have a spare ext4 root partition on the hard drive of the affected
> machine, so I booted to that, with 5.2.7, and got the following behaviour.
>
> dmesg:
>
> [ 55.139154] BTRFS: device fsid 5128caf4-b518-4b65-ae46-b5505281e500
> devid 1 transid 66785 /dev/sda4
> [ 55.139623] BTRFS info (device sda4): disk space caching is enabled
> [ 55.813959] BTRFS critical (device sda4): corrupt leaf: root=5
> block=38884884480 slot=1 ino=45745394, invalid inode generation: has
> 18446744073709551492 expect [0, 66786]
Please provide the following output:
# btrfs ins dump-tree -b 38884884480 /dev/sda4
I'm not sure if it's an really invalid case or a false alert I haven't
found.
For the workaround, just like Nikolay mentioned, reverted to older
kernel and remove the inode by:
# find <mnt> -inum 45745394 -exec rm {} \;
Thanks,
Qu
> [ 55.817296] BTRFS error (device sda4): block=38884884480 read time
> tree block corruption detected
> [ 55.817342] BTRFS warning (device sda4): failed to read fs tree: -5
> [ 55.834802] BTRFS error (device sda4): open_ctree failed
>
> /var/log/messages:
> Aug 10 11:59:05 retreat dbus[903]: [system] Activating service
> name='org.freedesktop.PolicyKit1' (using servicehelper)
> Aug 10 11:59:05 retreat polkitd[975]: started daemon version 0.105 using
> authority implementation `local' version `0.105'
> Aug 10 11:59:05 retreat dbus[903]: [system] Successfully activated
> service 'org.freedesktop.PolicyKit1'
> Aug 10 11:59:31 retreat kernel: [ 55.139154] BTRFS: device fsid
> 5128caf4-b518-4b65-ae46-b5505281e500 devid 1 transid 66785 /dev/sda4
> Aug 10 11:59:31 retreat kernel: [ 55.139623] BTRFS info (device sda4):
> disk space caching is enabled
>
> uname -a:
> Linux retreat 5.2.7 #1 SMP Wed Aug 7 23:53:42 BST 2019 x86_64 Intel(R)
> Core(TM) i5-4430 CPU @ 3.00GHz GenuineIntel GNU/Linux
>
> Rebooting with 5.1.4 showed no problems.
>
>
> A very similar kernel, with AMD rather than Intel processor options, is
> running on the Ryzen machine I am typing this on. I did have my hdd
> file system seem to hang, but not sure if that is related.
>
> I have not tried the intel kernel on my laptop, but the laptop is a lot
> older, as it is a core2duo.
>
> Seems a bit odd to me that 5.2.7 should show such an issue but 5.1.4 be
> OK with it.
>
> Pete
>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Mount failure with 5.2.7 but mounts with 5.1.4
2019-08-11 0:13 ` Qu Wenruo
@ 2019-08-11 16:23 ` Pete
2019-08-12 0:21 ` Qu Wenruo
0 siblings, 1 reply; 7+ messages in thread
From: Pete @ 2019-08-11 16:23 UTC (permalink / raw)
To: Qu Wenruo, Btrfs BTRFS
On 8/11/19 1:13 AM, Qu Wenruo wrote:
Qu, thank you.
>>
>> [ 55.139154] BTRFS: device fsid 5128caf4-b518-4b65-ae46-b5505281e500
>> devid 1 transid 66785 /dev/sda4
>> [ 55.139623] BTRFS info (device sda4): disk space caching is enabled
>> [ 55.813959] BTRFS critical (device sda4): corrupt leaf: root=5
>> block=38884884480 slot=1 ino=45745394, invalid inode generation: has
>> 18446744073709551492 expect [0, 66786]
>
> Please provide the following output:
>
> # btrfs ins dump-tree -b 38884884480 /dev/sda4
OK, it is long. Took a bit of a while as I thought it best to build an
uptodate version of brtfs-progs.
btrfs-progs v5.2.1
leaf 38884884480 items 24 free space 1441 generation 62836 owner FS_TREE
leaf 38884884480 flags 0x1(WRITTEN) backref revision 1
fs uuid 5128caf4-b518-4b65-ae46-b5505281e500
chunk uuid 8d513d0d-28d5-44d5-9bf7-f3e9f65e68c4
item 0 key (45745393 DIR_INDEX 2) itemoff 3957 itemsize 38
location key (45745394 INODE_ITEM 0) type FILE
transid 3486964995150852608 data_len 0 name_len 8
name: F6259d01
item 1 key (45745394 INODE_ITEM 0) itemoff 3797 itemsize 160
generation 1 transid 18446744073709551492 size 56218 nbytes 57344
block group 0 mode 100600 links 1 uid 1002 gid 100 rdev 0
sequence 0 flags 0x0(none)
atime 1395590849.0 (2014-03-23 16:07:29)
ctime 1395436187.0 (2014-03-21 21:09:47)
mtime 1395436187.0 (2014-03-21 21:09:47)
otime 0.0 (1970-01-01 01:00:00)
item 2 key (45745394 INODE_REF 45745393) itemoff 3779 itemsize 18
index 2 namelen 8 name: F6259d01
item 3 key (45745394 EXTENT_DATA 0) itemoff 3726 itemsize 53
generation 3 type 1 (regular)
extent data disk byte 747660742656 nr 57344
extent data offset 0 nr 57344 ram 57344
extent compression 0 (none)
item 4 key (45745395 INODE_ITEM 0) itemoff 3566 itemsize 160
generation 1 transid 18446744073709551492 size 16 nbytes 0
block group 0 mode 40700 links 1 uid 1002 gid 100 rdev 0
sequence 0 flags 0x0(none)
atime 1395590846.0 (2014-03-23 16:07:26)
ctime 1395436187.0 (2014-03-21 21:09:47)
mtime 1395436187.0 (2014-03-21 21:09:47)
otime 0.0 (1970-01-01 01:00:00)
item 5 key (45745395 INODE_REF 45615123) itemoff 3554 itemsize 12
index 40 namelen 2 name: E5
item 6 key (45745395 DIR_ITEM 3983833095) itemoff 3516 itemsize 38
location key (45745396 INODE_ITEM 0) type FILE
transid 53756160 data_len 0 name_len 8
name: 7EA03d01
item 7 key (45745395 DIR_INDEX 2) itemoff 3478 itemsize 38
location key (45745396 INODE_ITEM 0) type FILE
transid 53756160 data_len 0 name_len 8
name: 7EA03d01
item 8 key (45745396 INODE_ITEM 0) itemoff 3318 itemsize 160
generation 1 transid 18446744073709551492 size 16538 nbytes 20480
block group 0 mode 100600 links 1 uid 1002 gid 100 rdev 0
sequence 0 flags 0x0(none)
atime 1395590851.0 (2014-03-23 16:07:31)
ctime 1395436188.0 (2014-03-21 21:09:48)
mtime 1395436188.0 (2014-03-21 21:09:48)
otime 0.0 (1970-01-01 01:00:00)
item 9 key (45745396 INODE_REF 45745395) itemoff 3300 itemsize 18
index 2 namelen 8 name: 7EA03d01
item 10 key (45745396 EXTENT_DATA 0) itemoff 3247 itemsize 53
generation 3 type 1 (regular)
extent data disk byte 749606772736 nr 20480
extent data offset 0 nr 20480 ram 20480
extent compression 0 (none)
item 11 key (45745397 INODE_ITEM 0) itemoff 3087 itemsize 160
generation 1 transid 18446744073709551492 size 56776 nbytes 57344
block group 0 mode 100600 links 1 uid 1002 gid 100 rdev 0
sequence 0 flags 0x0(none)
atime 1395590846.0 (2014-03-23 16:07:26)
ctime 1395436188.0 (2014-03-21 21:09:48)
mtime 1395436188.0 (2014-03-21 21:09:48)
otime 0.0 (1970-01-01 01:00:00)
item 12 key (45745397 INODE_REF 45744991) itemoff 3069 itemsize 18
index 3 namelen 8 name: 20800d01
item 13 key (45745397 EXTENT_DATA 0) itemoff 3016 itemsize 53
generation 3 type 1 (regular)
extent data disk byte 746701180928 nr 57344
extent data offset 0 nr 57344 ram 57344
extent compression 0 (none)
item 14 key (45745398 INODE_ITEM 0) itemoff 2856 itemsize 160
generation 1 transid 18446744073709551492 size 16 nbytes 0
block group 0 mode 40700 links 1 uid 1002 gid 100 rdev 0
sequence 0 flags 0x0(none)
atime 1395590844.0 (2014-03-23 16:07:24)
ctime 1395436188.0 (2014-03-21 21:09:48)
mtime 1395436188.0 (2014-03-21 21:09:48)
otime 0.0 (1970-01-01 01:00:00)
item 15 key (45745398 INODE_REF 45615119) itemoff 2844 itemsize 12
index 34 namelen 2 name: A4
item 16 key (45745398 DIR_ITEM 3267253918) itemoff 2806 itemsize 38
location key (45745399 INODE_ITEM 0) type FILE
transid 0 data_len 0 name_len 8
name: 21893d01
item 17 key (45745398 DIR_INDEX 2) itemoff 2768 itemsize 38
location key (45745399 INODE_ITEM 0) type FILE
transid 0 data_len 0 name_len 8
name: 21893d01
item 18 key (45745399 INODE_ITEM 0) itemoff 2608 itemsize 160
generation 1 transid 18446744073709551492 size 91218 nbytes 94208
block group 0 mode 100600 links 1 uid 1002 gid 100 rdev 0
sequence 0 flags 0x0(none)
atime 1395590849.0 (2014-03-23 16:07:29)
ctime 1395436189.0 (2014-03-21 21:09:49)
mtime 1395436189.0 (2014-03-21 21:09:49)
otime 0.0 (1970-01-01 01:00:00)
item 19 key (45745399 INODE_REF 45745398) itemoff 2590 itemsize 18
index 2 namelen 8 name: 21893d01
item 20 key (45745399 EXTENT_DATA 0) itemoff 2537 itemsize 53
generation 3 type 1 (regular)
extent data disk byte 1797652480 nr 94208
extent data offset 0 nr 94208 ram 94208
extent compression 0 (none)
item 21 key (45745400 INODE_ITEM 0) itemoff 2377 itemsize 160
generation 20 transid 62836 size 297 nbytes 297
block group 0 mode 100755 links 1 uid 0 gid 0 rdev 0
sequence 11 flags 0x0(none)
atime 1558793952.717852250 (2019-05-25 15:19:12)
ctime 1395594875.621986903 (2014-03-23 17:14:35)
mtime 1395594875.621986903 (2014-03-23 17:14:35)
otime 0.0 (1970-01-01 01:00:00)
item 22 key (45745400 INODE_REF 256) itemoff 2359 itemsize 18
index 15 namelen 8 name: snapshot
item 23 key (45745400 EXTENT_DATA 0) itemoff 2041 itemsize 318
generation 85 type 0 (inline)
inline extent data size 297 ram_bytes 297 compression 0 (none)
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Mount failure with 5.2.7 but mounts with 5.1.4
2019-08-11 16:23 ` Pete
@ 2019-08-12 0:21 ` Qu Wenruo
2019-08-13 7:02 ` Pete
0 siblings, 1 reply; 7+ messages in thread
From: Qu Wenruo @ 2019-08-12 0:21 UTC (permalink / raw)
To: Pete, Btrfs BTRFS
[-- Attachment #1.1: Type: text/plain, Size: 7022 bytes --]
On 2019/8/12 上午12:23, Pete wrote:
> On 8/11/19 1:13 AM, Qu Wenruo wrote:
>
> Qu, thank you.
>
>>>
>>> [ 55.139154] BTRFS: device fsid 5128caf4-b518-4b65-ae46-b5505281e500
>>> devid 1 transid 66785 /dev/sda4
>>> [ 55.139623] BTRFS info (device sda4): disk space caching is enabled
>>> [ 55.813959] BTRFS critical (device sda4): corrupt leaf: root=5
>>> block=38884884480 slot=1 ino=45745394, invalid inode generation: has
>>> 18446744073709551492 expect [0, 66786]
>>
>> Please provide the following output:
>>
>> # btrfs ins dump-tree -b 38884884480 /dev/sda4
>
> OK, it is long. Took a bit of a while as I thought it best to build an
> uptodate version of brtfs-progs.
>
> btrfs-progs v5.2.1
> leaf 38884884480 items 24 free space 1441 generation 62836 owner FS_TREE
> leaf 38884884480 flags 0x1(WRITTEN) backref revision 1
> fs uuid 5128caf4-b518-4b65-ae46-b5505281e500
> chunk uuid 8d513d0d-28d5-44d5-9bf7-f3e9f65e68c4
> item 0 key (45745393 DIR_INDEX 2) itemoff 3957 itemsize 38
> location key (45745394 INODE_ITEM 0) type FILE
> transid 3486964995150852608 data_len 0 name_len 8
> name: F6259d01
The transid of this inode index is also strange.
> item 1 key (45745394 INODE_ITEM 0) itemoff 3797 itemsize 160
> generation 1 transid 18446744073709551492 size 56218 nbytes 57344
The offending inode item.
> block group 0 mode 100600 links 1 uid 1002 gid 100 rdev 0
> sequence 0 flags 0x0(none)
> atime 1395590849.0 (2014-03-23 16:07:29)
> ctime 1395436187.0 (2014-03-21 21:09:47)
> mtime 1395436187.0 (2014-03-21 21:09:47)
It's an old fs, maybe some older kernel caused such strange behavior.
> otime 0.0 (1970-01-01 01:00:00)
> item 2 key (45745394 INODE_REF 45745393) itemoff 3779 itemsize 18
> index 2 namelen 8 name: F6259d01
> item 3 key (45745394 EXTENT_DATA 0) itemoff 3726 itemsize 53
> generation 3 type 1 (regular)
This looks like the correct generation, 3.
> extent data disk byte 747660742656 nr 57344
> extent data offset 0 nr 57344 ram 57344
> extent compression 0 (none)
> item 4 key (45745395 INODE_ITEM 0) itemoff 3566 itemsize 160
> generation 1 transid 18446744073709551492 size 16 nbytes 0
This happens again, so definitely not a false alert.
> block group 0 mode 40700 links 1 uid 1002 gid 100 rdev 0
> sequence 0 flags 0x0(none)
> atime 1395590846.0 (2014-03-23 16:07:26)
> ctime 1395436187.0 (2014-03-21 21:09:47)
> mtime 1395436187.0 (2014-03-21 21:09:47)
> otime 0.0 (1970-01-01 01:00:00)
> item 5 key (45745395 INODE_REF 45615123) itemoff 3554 itemsize 12
> index 40 namelen 2 name: E5
> item 6 key (45745395 DIR_ITEM 3983833095) itemoff 3516 itemsize 38
> location key (45745396 INODE_ITEM 0) type FILE
> transid 53756160 data_len 0 name_len 8
Strange transid again.
> name: 7EA03d01
> item 7 key (45745395 DIR_INDEX 2) itemoff 3478 itemsize 38
> location key (45745396 INODE_ITEM 0) type FILE
> transid 53756160 data_len 0 name_len 8
And again.
> name: 7EA03d01
> item 8 key (45745396 INODE_ITEM 0) itemoff 3318 itemsize 160
> generation 1 transid 18446744073709551492 size 16538 nbytes 20480
And again.
So the workaround won't work until you delete all those 2014 files.
I'd recommend to copy the data to a new btrfs using 5.1 kernel.
Thanks,
Qu
> block group 0 mode 100600 links 1 uid 1002 gid 100 rdev 0
> sequence 0 flags 0x0(none)
> atime 1395590851.0 (2014-03-23 16:07:31)
> ctime 1395436188.0 (2014-03-21 21:09:48)
> mtime 1395436188.0 (2014-03-21 21:09:48)
> otime 0.0 (1970-01-01 01:00:00)
> item 9 key (45745396 INODE_REF 45745395) itemoff 3300 itemsize 18
> index 2 namelen 8 name: 7EA03d01
> item 10 key (45745396 EXTENT_DATA 0) itemoff 3247 itemsize 53
> generation 3 type 1 (regular)
> extent data disk byte 749606772736 nr 20480
> extent data offset 0 nr 20480 ram 20480
> extent compression 0 (none)
> item 11 key (45745397 INODE_ITEM 0) itemoff 3087 itemsize 160
> generation 1 transid 18446744073709551492 size 56776 nbytes 57344
> block group 0 mode 100600 links 1 uid 1002 gid 100 rdev 0
> sequence 0 flags 0x0(none)
> atime 1395590846.0 (2014-03-23 16:07:26)
> ctime 1395436188.0 (2014-03-21 21:09:48)
> mtime 1395436188.0 (2014-03-21 21:09:48)
> otime 0.0 (1970-01-01 01:00:00)
> item 12 key (45745397 INODE_REF 45744991) itemoff 3069 itemsize 18
> index 3 namelen 8 name: 20800d01
> item 13 key (45745397 EXTENT_DATA 0) itemoff 3016 itemsize 53
> generation 3 type 1 (regular)
> extent data disk byte 746701180928 nr 57344
> extent data offset 0 nr 57344 ram 57344
> extent compression 0 (none)
> item 14 key (45745398 INODE_ITEM 0) itemoff 2856 itemsize 160
> generation 1 transid 18446744073709551492 size 16 nbytes 0
> block group 0 mode 40700 links 1 uid 1002 gid 100 rdev 0
> sequence 0 flags 0x0(none)
> atime 1395590844.0 (2014-03-23 16:07:24)
> ctime 1395436188.0 (2014-03-21 21:09:48)
> mtime 1395436188.0 (2014-03-21 21:09:48)
> otime 0.0 (1970-01-01 01:00:00)
> item 15 key (45745398 INODE_REF 45615119) itemoff 2844 itemsize 12
> index 34 namelen 2 name: A4
> item 16 key (45745398 DIR_ITEM 3267253918) itemoff 2806 itemsize 38
> location key (45745399 INODE_ITEM 0) type FILE
> transid 0 data_len 0 name_len 8
> name: 21893d01
> item 17 key (45745398 DIR_INDEX 2) itemoff 2768 itemsize 38
> location key (45745399 INODE_ITEM 0) type FILE
> transid 0 data_len 0 name_len 8
> name: 21893d01
> item 18 key (45745399 INODE_ITEM 0) itemoff 2608 itemsize 160
> generation 1 transid 18446744073709551492 size 91218 nbytes 94208
> block group 0 mode 100600 links 1 uid 1002 gid 100 rdev 0
> sequence 0 flags 0x0(none)
> atime 1395590849.0 (2014-03-23 16:07:29)
> ctime 1395436189.0 (2014-03-21 21:09:49)
> mtime 1395436189.0 (2014-03-21 21:09:49)
> otime 0.0 (1970-01-01 01:00:00)
> item 19 key (45745399 INODE_REF 45745398) itemoff 2590 itemsize 18
> index 2 namelen 8 name: 21893d01
> item 20 key (45745399 EXTENT_DATA 0) itemoff 2537 itemsize 53
> generation 3 type 1 (regular)
> extent data disk byte 1797652480 nr 94208
> extent data offset 0 nr 94208 ram 94208
> extent compression 0 (none)
> item 21 key (45745400 INODE_ITEM 0) itemoff 2377 itemsize 160
> generation 20 transid 62836 size 297 nbytes 297
> block group 0 mode 100755 links 1 uid 0 gid 0 rdev 0
> sequence 11 flags 0x0(none)
> atime 1558793952.717852250 (2019-05-25 15:19:12)
> ctime 1395594875.621986903 (2014-03-23 17:14:35)
> mtime 1395594875.621986903 (2014-03-23 17:14:35)
> otime 0.0 (1970-01-01 01:00:00)
> item 22 key (45745400 INODE_REF 256) itemoff 2359 itemsize 18
> index 15 namelen 8 name: snapshot
> item 23 key (45745400 EXTENT_DATA 0) itemoff 2041 itemsize 318
> generation 85 type 0 (inline)
> inline extent data size 297 ram_bytes 297 compression 0 (none)
>
>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Mount failure with 5.2.7 but mounts with 5.1.4
2019-08-12 0:21 ` Qu Wenruo
@ 2019-08-13 7:02 ` Pete
0 siblings, 0 replies; 7+ messages in thread
From: Pete @ 2019-08-13 7:02 UTC (permalink / raw)
To: Qu Wenruo, Btrfs BTRFS
On 8/12/19 1:21 AM, Qu Wenruo wrote:
> The offending inode item.
>
>> block group 0 mode 100600 links 1 uid 1002 gid 100 rdev 0
>> sequence 0 flags 0x0(none)
>> atime 1395590849.0 (2014-03-23 16:07:29)
>> ctime 1395436187.0 (2014-03-21 21:09:47)
>> mtime 1395436187.0 (2014-03-21 21:09:47)
>
> It's an old fs, maybe some older kernel caused such strange behavior.
>
Whilst tidying up the system I did find some modules from a 3.* series
kernel.
> So the workaround won't work until you delete all those 2014 files.
I left it running to do that.
>
> I'd recommend to copy the data to a new btrfs using 5.1 kernel.
>
OK. Its due an update shortly anyway. Perhaps I'll treat it to a SSD,
as it will make updates quicker.
> Thanks,
> Qu
Thank you.
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2019-08-13 7:03 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-08-10 15:54 Mount failure with 5.2.7 but mounts with 5.1.4 Peter Chant
2019-08-10 17:53 ` Nikolay Borisov
2019-08-10 18:19 ` Pete
2019-08-11 0:13 ` Qu Wenruo
2019-08-11 16:23 ` Pete
2019-08-12 0:21 ` Qu Wenruo
2019-08-13 7:02 ` Pete
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).