Unmounting USB pen takes a lot of time.

Xwang · 2021-01-28 13:05:14

Since some days the unmounting of an USB pendrive using KDE takes a lot of time.
The USB pen is formatted with exfat and in journalctl I see errors like the following one:

gen 28 13:32:57 n752vx kernel: INFO: task pool-udisksd:22514 blocked for more than 122 seconds.
gen 28 13:32:57 n752vx kernel:       Tainted: P          IOE     5.10.11-arch1-1 #1
gen 28 13:32:57 n752vx kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
gen 28 13:32:57 n752vx kernel: task:pool-udisksd    state:D stack:    0 pid:22514 ppid:     1 flags:0x00004080
gen 28 13:32:57 n752vx kernel: Call Trace:
gen 28 13:32:57 n752vx kernel:  __schedule+0x295/0x810
gen 28 13:32:57 n752vx kernel:  schedule+0x5b/0xc0
gen 28 13:32:57 n752vx kernel:  wb_wait_for_completion+0x79/0xb0
gen 28 13:32:57 n752vx kernel:  ? wait_woken+0x80/0x80
gen 28 13:32:57 n752vx kernel:  __writeback_inodes_sb_nr+0xa3/0xd0
gen 28 13:32:57 n752vx kernel:  sync_filesystem+0x29/0x90
gen 28 13:32:57 n752vx kernel:  generic_shutdown_super+0x22/0x100
gen 28 13:32:57 n752vx kernel:  kill_block_super+0x21/0x50
gen 28 13:32:57 n752vx kernel:  deactivate_locked_super+0x36/0x90
gen 28 13:32:57 n752vx kernel:  cleanup_mnt+0x12d/0x190
gen 28 13:32:57 n752vx kernel:  task_work_run+0x5c/0x90
gen 28 13:32:57 n752vx kernel:  exit_to_user_mode_prepare+0xf7/0x120
gen 28 13:32:57 n752vx kernel:  syscall_exit_to_user_mode+0x28/0x160
gen 28 13:32:57 n752vx kernel:  entry_SYSCALL_64_after_hwframe+0x44/0xa9
gen 28 13:32:57 n752vx kernel: RIP: 0033:0x7f8d005ba2cb
gen 28 13:32:57 n752vx kernel: RSP: 002b:00007f8cff4aa4c8 EFLAGS: 00000246 ORIG_RAX: 00000000000000a6
gen 28 13:32:57 n752vx kernel: RAX: 0000000000000000 RBX: 00007f8d00bf3264 RCX: 00007f8d005ba2cb
gen 28 13:32:57 n752vx kernel: RDX: 000000000000001c RSI: 0000000000000000 RDI: 00007f8cf800ed10
gen 28 13:32:57 n752vx kernel: RBP: 00007f8cf805c4b0 R08: 0000000000000000 R09: 00007f8cf8000080
gen 28 13:32:57 n752vx kernel: R10: 0000000000000010 R11: 0000000000000246 R12: 0000000000000000
gen 28 13:32:57 n752vx kernel: R13: 00007f8cf800ed10 R14: 00007f8cf805c5c0 R15: 00007f8cf8063010

Is it a bug?
Does anyone is experiencing the same issue?

seth · 2021-01-28 13:15:29

Does it also take long if your run "sudo sync" before you umount it?
Are there other errors (I/O related? "Mode sense"? DRDY?)

Xwang · 2021-01-28 14:37:51

seth wrote:

Does it also take long if your run "sudo sync" before you umount it?
Are there other errors (I/O related? "Mode sense"? DRDY?)

I've given sudo sync about 10 minutes ago and it is still running and journalctl says:

gen 28 14:36:27 n752vx kernel: INFO: task sync:3897 blocked for more than 614 seconds.
gen 28 14:36:27 n752vx kernel:       Tainted: P          IOE     5.10.11-arch1-1 #1
gen 28 14:36:27 n752vx kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
gen 28 14:36:27 n752vx kernel: task:sync            state:D stack:    0 pid: 3897 ppid:  3890 flags:0x00004080
gen 28 14:36:27 n752vx kernel: Call Trace:
gen 28 14:36:27 n752vx kernel:  __schedule+0x295/0x810
gen 28 14:36:27 n752vx kernel:  schedule+0x5b/0xc0
gen 28 14:36:27 n752vx kernel:  wb_wait_for_completion+0x79/0xb0
gen 28 14:36:27 n752vx kernel:  ? wait_woken+0x80/0x80
gen 28 14:36:27 n752vx kernel:  sync_inodes_sb+0xd6/0x290
gen 28 14:36:27 n752vx kernel:  ? __x64_sys_tee+0xd0/0xd0
gen 28 14:36:27 n752vx kernel:  iterate_supers+0x98/0xf0
gen 28 14:36:27 n752vx kernel:  ksys_sync+0x40/0xb0
gen 28 14:36:27 n752vx kernel:  __do_sys_sync+0xa/0x10
gen 28 14:36:27 n752vx kernel:  do_syscall_64+0x33/0x40
gen 28 14:36:27 n752vx kernel:  entry_SYSCALL_64_after_hwframe+0x44/0xa9
gen 28 14:36:27 n752vx kernel: RIP: 0033:0x7fb7034c3deb
gen 28 14:36:27 n752vx kernel: RSP: 002b:00007ffc18a1c758 EFLAGS: 00000246 ORIG_RAX: 00000000000000a2
gen 28 14:36:27 n752vx kernel: RAX: ffffffffffffffda RBX: 00007ffc18a1c898 RCX: 00007fb7034c3deb
gen 28 14:36:27 n752vx kernel: RDX: 00007fb703592301 RSI: 0000000000000000 RDI: 00007fb70355b447
gen 28 14:36:27 n752vx kernel: RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000
gen 28 14:36:27 n752vx kernel: R10: 0000558e70fa2340 R11: 0000000000000246 R12: 0000000000000000
gen 28 14:36:27 n752vx kernel: R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000

EDIT: after the execution of sudo sync, the unmounting has been immediate.

seth · 2021-01-28 14:51:21

There's either an issue w/ the FS, the bus or the device.
Does it sync faster on a different software stack (live distro) or host system (other computer)?

Xwang · 2021-01-29 08:26:07

seth wrote:

There's either an issue w/ the FS, the bus or the device.
Does it sync faster on a different software stack (live distro) or host system (other computer)?

I've tried with the same device, on the same laptop with the lts kernel obtaining the same issue.
Then I decided to format again the peen drive and now the problem seems to be solved both on standard and lts kernel.
So I think it was a somewhat corrupted filesystem not detected by fsck.

seth · 2021-01-29 08:46:10

You want to test for https://wiki.archlinux.org/index.php/Badblocks

Xwang · 2021-01-29 09:10:57

seth wrote:

You want to test for https://wiki.archlinux.org/index.php/Badblocks

Since I've already restored 70GB of data on it, I'm executing the non destructive test on the partition with this command sudo badblocks -nsv /dev/sdd1 and it will take about 8 hours.
In case no errors will be found, is it sufficient or should I run the destructive and/or also the test on /dev/sdd ?

seth · 2021-01-29 12:32:05

No, the non-destructive test is gonna be fine (just much slower)

Xwang · 2021-01-29 12:37:36

seth wrote:

No, the non-destructive test is gonna be fine (just much slower)

It is at 33% now.

[sdd] 242221056 512-byte logical blocks: (124 GB / 116 GiB)
[2141.617090] sd 4: 0: 0: 0: [sdd] Write Protect is off
[2141.617095] sd 4: 0: 0: 0: [sdd] Mode Sense: 45 00 00 00
[2141.617480] sd 4: 0: 0: 0: [sdd] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[2143.510528] sdd: sdd1
[2143.512679] sd 4: 0: 0: 0: [sdd] Attached SCSI removable disk
[andreak @ n752vx ~] $ sudo badblocks -nsv / dev / sdd1
Search for invalid blocks in non-destructive read-write mode
From block 0 to block 121104383
Search for invalid blocks (test in non-destructive read-write mode)

Does it means that once this phase will be ended it will run another one from block 121104383 to 242221056 ?

Last edited by Xwang (2021-01-29 12:38:36)

Arch Linux

#1 2021-01-28 13:05:14

Unmounting USB pen takes a lot of time.

#2 2021-01-28 13:15:29

Re: Unmounting USB pen takes a lot of time.

#3 2021-01-28 14:37:51

Re: Unmounting USB pen takes a lot of time.

#4 2021-01-28 14:51:21

Re: Unmounting USB pen takes a lot of time.

#5 2021-01-29 08:26:07

Re: Unmounting USB pen takes a lot of time.

#6 2021-01-29 08:46:10

Re: Unmounting USB pen takes a lot of time.

#7 2021-01-29 09:10:57

Re: Unmounting USB pen takes a lot of time.

#8 2021-01-29 12:32:05

Re: Unmounting USB pen takes a lot of time.

#9 2021-01-29 12:37:36

Re: Unmounting USB pen takes a lot of time.

Board footer