* XFS volume unmounts itself with lots of kernel logs generated
@ 2022-01-12 12:11 Well Loaded
2022-01-12 17:21 ` Darrick J. Wong
0 siblings, 1 reply; 4+ messages in thread
From: Well Loaded @ 2022-01-12 12:11 UTC (permalink / raw)
To: linux-xfs
I'm having issues with my XFS volume. It mounts itself as soon as some
medium load happens e.g. can open/view a text file, it crashes under
rsync. This below is the relevant part of the syslog:
Jan 12 11:42:01 NAS kernel: [ 3179.130696] XFS (sdc1): Unmounting Filesystem
Jan 12 11:42:03 NAS kernel: [ 3180.798027] XFS (sdc1): Mounting V4
Filesystem
Jan 12 11:42:03 NAS kernel: [ 3180.921496] XFS (sdc1): Ending clean mount
Jan 12 11:47:22 NAS kernel: [ 3498.175610] CPU: 5 PID: 5404 Comm: rsync
Not tainted 4.18.0-0.bpo.1-amd64 #1 Debian 4.18.6-1~bpo9+1
Jan 12 11:47:22 NAS kernel: [ 3498.175616] Hardware name: VMware, Inc.
VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00
12/12/2018
Jan 12 11:47:22 NAS kernel: [ 3498.175622] Call Trace:
Jan 12 11:47:22 NAS kernel: [ 3498.175629] dump_stack+0x5c/0x7b
Jan 12 11:47:22 NAS kernel: [ 3498.175688] xfs_trans_cancel+0x116/0x140
[xfs]
Jan 12 11:47:22 NAS kernel: [ 3498.175736] xfs_create+0x41d/0x640 [xfs]
Jan 12 11:47:22 NAS kernel: [ 3498.175780]
xfs_generic_create+0x241/0x2e0 [xfs]
Jan 12 11:47:22 NAS kernel: [ 3498.175808] ? d_splice_alias+0x139/0x3f0
Jan 12 11:47:22 NAS kernel: [ 3498.175812] path_openat+0x141c/0x14d0
Jan 12 11:47:22 NAS kernel: [ 3498.175816] do_filp_open+0x99/0x110
Jan 12 11:47:22 NAS kernel: [ 3498.175820] ? __check_object_size+0x98/0x1a0
Jan 12 11:47:22 NAS kernel: [ 3498.175823] ? do_sys_open+0x12e/0x210
Jan 12 11:47:22 NAS kernel: [ 3498.175825] do_sys_open+0x12e/0x210
Jan 12 11:47:22 NAS kernel: [ 3498.175829] do_syscall_64+0x55/0x110
Jan 12 11:47:22 NAS kernel: [ 3498.175832]
entry_SYSCALL_64_after_hwframe+0x44/0xa9
Jan 12 11:47:22 NAS kernel: [ 3498.175836] RIP: 0033:0x7f6652f836f0
Jan 12 11:47:22 NAS kernel: [ 3498.175837] Code: 00 f7 d8 64 89 01 48 83
c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 83 3d 19 30 2c 00
00 75 10 b8 02 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 31 c3 48 83 ec 08
e8 fe 9d 01 00 48 89 04 24
Jan 12 11:47:22 NAS kernel: [ 3498.175875] RSP: 002b:00007ffc53860668
EFLAGS: 00000246 ORIG_RAX: 0000000000000002
Jan 12 11:47:22 NAS kernel: [ 3498.175877] RAX: ffffffffffffffda RBX:
0000000000000000 RCX: 00007f6652f836f0
Jan 12 11:47:22 NAS kernel: [ 3498.175879] RDX: 0000000000000180 RSI:
00000000000000c2 RDI: 00007ffc538628d0
Jan 12 11:47:22 NAS kernel: [ 3498.175881] RBP: 000000000003a2f8 R08:
000000000000ffff R09: 67756c702e707061
Jan 12 11:47:22 NAS kernel: [ 3498.175882] R10: 0000000000000000 R11:
0000000000000246 R12: 00007ffc53862942
Jan 12 11:47:22 NAS kernel: [ 3498.175884] R13: 8421084210842109 R14:
00000000000000c2 R15: 00007f6653011540
Jan 12 11:47:22 NAS kernel: [ 3498.175888] XFS (sdc1):
xfs_do_force_shutdown(0x8) called from line 1018 of file
/build/linux-GVmoCH/linux-4.18.6/fs/xfs/xfs_trans.c. Return address =
00000000ddf97241
I have already performed xds_repair /dev/sdc1 and xfs_repair -L
/dev/sdc1 they both completed successfully but the issue is still happening.
Is there anything else I can try? Is this perhaps a bug?
Thanks!
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: XFS volume unmounts itself with lots of kernel logs generated
2022-01-12 12:11 XFS volume unmounts itself with lots of kernel logs generated Well Loaded
@ 2022-01-12 17:21 ` Darrick J. Wong
0 siblings, 0 replies; 4+ messages in thread
From: Darrick J. Wong @ 2022-01-12 17:21 UTC (permalink / raw)
To: Well Loaded; +Cc: linux-xfs
On Wed, Jan 12, 2022 at 02:11:13PM +0200, Well Loaded wrote:
> I'm having issues with my XFS volume. It mounts itself as soon as some
> medium load happens e.g. can open/view a text file, it crashes under rsync.
> This below is the relevant part of the syslog:
Is the disk full?
--D
>
>
> Jan 12 11:42:01 NAS kernel: [ 3179.130696] XFS (sdc1): Unmounting Filesystem
> Jan 12 11:42:03 NAS kernel: [ 3180.798027] XFS (sdc1): Mounting V4
> Filesystem
> Jan 12 11:42:03 NAS kernel: [ 3180.921496] XFS (sdc1): Ending clean mount
> Jan 12 11:47:22 NAS kernel: [ 3498.175610] CPU: 5 PID: 5404 Comm: rsync Not
> tainted 4.18.0-0.bpo.1-amd64 #1 Debian 4.18.6-1~bpo9+1
> Jan 12 11:47:22 NAS kernel: [ 3498.175616] Hardware name: VMware, Inc.
> VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00
> 12/12/2018
> Jan 12 11:47:22 NAS kernel: [ 3498.175622] Call Trace:
> Jan 12 11:47:22 NAS kernel: [ 3498.175629] dump_stack+0x5c/0x7b
> Jan 12 11:47:22 NAS kernel: [ 3498.175688] xfs_trans_cancel+0x116/0x140
> [xfs]
> Jan 12 11:47:22 NAS kernel: [ 3498.175736] xfs_create+0x41d/0x640 [xfs]
> Jan 12 11:47:22 NAS kernel: [ 3498.175780] xfs_generic_create+0x241/0x2e0
> [xfs]
> Jan 12 11:47:22 NAS kernel: [ 3498.175808] ? d_splice_alias+0x139/0x3f0
> Jan 12 11:47:22 NAS kernel: [ 3498.175812] path_openat+0x141c/0x14d0
> Jan 12 11:47:22 NAS kernel: [ 3498.175816] do_filp_open+0x99/0x110
> Jan 12 11:47:22 NAS kernel: [ 3498.175820] ? __check_object_size+0x98/0x1a0
> Jan 12 11:47:22 NAS kernel: [ 3498.175823] ? do_sys_open+0x12e/0x210
> Jan 12 11:47:22 NAS kernel: [ 3498.175825] do_sys_open+0x12e/0x210
> Jan 12 11:47:22 NAS kernel: [ 3498.175829] do_syscall_64+0x55/0x110
> Jan 12 11:47:22 NAS kernel: [ 3498.175832]
> entry_SYSCALL_64_after_hwframe+0x44/0xa9
> Jan 12 11:47:22 NAS kernel: [ 3498.175836] RIP: 0033:0x7f6652f836f0
> Jan 12 11:47:22 NAS kernel: [ 3498.175837] Code: 00 f7 d8 64 89 01 48 83 c8
> ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 83 3d 19 30 2c 00 00 75
> 10 b8 02 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 31 c3 48 83 ec 08 e8 fe 9d 01
> 00 48 89 04 24
> Jan 12 11:47:22 NAS kernel: [ 3498.175875] RSP: 002b:00007ffc53860668
> EFLAGS: 00000246 ORIG_RAX: 0000000000000002
> Jan 12 11:47:22 NAS kernel: [ 3498.175877] RAX: ffffffffffffffda RBX:
> 0000000000000000 RCX: 00007f6652f836f0
> Jan 12 11:47:22 NAS kernel: [ 3498.175879] RDX: 0000000000000180 RSI:
> 00000000000000c2 RDI: 00007ffc538628d0
> Jan 12 11:47:22 NAS kernel: [ 3498.175881] RBP: 000000000003a2f8 R08:
> 000000000000ffff R09: 67756c702e707061
> Jan 12 11:47:22 NAS kernel: [ 3498.175882] R10: 0000000000000000 R11:
> 0000000000000246 R12: 00007ffc53862942
> Jan 12 11:47:22 NAS kernel: [ 3498.175884] R13: 8421084210842109 R14:
> 00000000000000c2 R15: 00007f6653011540
> Jan 12 11:47:22 NAS kernel: [ 3498.175888] XFS (sdc1):
> xfs_do_force_shutdown(0x8) called from line 1018 of file
> /build/linux-GVmoCH/linux-4.18.6/fs/xfs/xfs_trans.c. Return address =
> 00000000ddf97241
>
>
> I have already performed xds_repair /dev/sdc1 and xfs_repair -L /dev/sdc1
> they both completed successfully but the issue is still happening.
>
> Is there anything else I can try? Is this perhaps a bug?
>
> Thanks!
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: XFS volume unmounts itself with lots of kernel logs generated
2022-01-13 8:00 Well Loaded
@ 2022-01-17 19:32 ` Well Loaded
0 siblings, 0 replies; 4+ messages in thread
From: Well Loaded @ 2022-01-17 19:32 UTC (permalink / raw)
To: linux-xfs; +Cc: bf0b1c63-8fee-112b-fc6c-801593ef4f23
I am really stuck with this, can I please get some help?
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: XFS volume unmounts itself with lots of kernel logs generated
@ 2022-01-13 8:00 Well Loaded
2022-01-17 19:32 ` Well Loaded
0 siblings, 1 reply; 4+ messages in thread
From: Well Loaded @ 2022-01-13 8:00 UTC (permalink / raw)
To: linux-xfs
Not full but it's 80% currently.
The metadata dump of this broken XFS volume can be found at the link
here below:
https://ufile.io/5gzf475e
(60MB compressed)
On this topic I have a question. As I have a brother system with
identical hardware, partition size etc, could I benefit from a
dump/import of the brother (working) system?
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2022-01-17 19:32 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-01-12 12:11 XFS volume unmounts itself with lots of kernel logs generated Well Loaded
2022-01-12 17:21 ` Darrick J. Wong
2022-01-13 8:00 Well Loaded
2022-01-17 19:32 ` Well Loaded
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.