Linux-BTRFS Archive on lore.kernel.org
 help / color / Atom feed
* 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, back to index

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

Linux-BTRFS Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-btrfs/0 linux-btrfs/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-btrfs linux-btrfs/ https://lore.kernel.org/linux-btrfs \
		linux-btrfs@vger.kernel.org linux-btrfs@archiver.kernel.org
	public-inbox-index linux-btrfs


Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-btrfs


AGPL code for this site: git clone https://public-inbox.org/ public-inbox