https://bugs.kde.org/show_bug.cgi?id=525116
Bug ID: 525116
Summary: Moving a file to trash blocks for ~40 s when a mounted
network share is unreachable
Classification: Frameworks and Libraries
Product: frameworks-kio
Version First 6.24.0
Reported In:
Platform: Other
OS: Linux
Status: REPORTED
Keywords: efficiency-and-performance
Severity: normal
Priority: NOR
Component: Trash
Assignee: [email protected]
Reporter: [email protected]
CC: [email protected]
Target Milestone: ---
SUMMARY
kio_trash scans *all* mount points on a trash operation and stats
<mountpoint>/.Trash and <mountpoint>/.Trash-1000 on each one
(TrashImpl::scanTrashDirectories, src/kioworkers/trash/trashimpl.cpp).
If a CIFS share is still mounted but its server is not reachable in the
current network — laptop moved to another site, VPN down — each of those
stats blocks in the CIFS timeout. With two such shares mounted, a single
"Move to Trash" in Dolphin takes ~40 s. "Delete permanently" and
`gio trash` stay instant because they never touch the trash worker.
The file being trashed is on the same filesystem as $HOME, so those
mounts are irrelevant to the operation being performed.
STEPS TO REPRODUCE
1. Mount an SMB share (e.g. via fstab + x-systemd.automount).
2. Make the server unreachable while the share stays mounted, e.g.
mount a local Samba share over 127.0.0.1 and then drop the traffic:
sudo mount -t cifs //127.0.0.1/home /mnt/test -o ...,soft
sudo iptables -I OUTPUT 1 -o lo -d 127.0.0.1 -p tcp --dport 445 -j DROP
3. In Dolphin, move a file from $HOME to the trash.
OBSERVED RESULT
The operation blocks for tens of seconds. Measured on the real case
(two unreachable SMB shares, /mnt/lw-u and /mnt/agorum):
rm 1 ms
gio trash 3 ms
kioclient move file://... trash:/ 41254 ms
stat /mnt/lw-u/.Trash-1000 19775 ms
stat /mnt/agorum/.Trash 20474 ms
After unmounting the two dead shares, the same kioclient call takes
126 ms. Kernel stack of the blocked worker while it hangs:
[<0>] wait_for_response+0xc3/0x120 [cifs]
[<0>] compound_send_recv+0x6c8/0x1470 [cifs]
[<0>] smb2_compound_op+0x25cd/0x2b40 [cifs]
[<0>] smb2_query_path_info+0x216/0xa20 [cifs]
strace of the worker, trashing a file that lives on / (same filesystem
as $HOME), with an unrelated CIFS mount present:
newfstatat(AT_FDCWD, "/mnt/testcifs/.Trash", ..., AT_SYMLINK_NOFOLLOW) = -1
ENOENT
newfstatat(AT_FDCWD, "/mnt/testcifs/.Trash-1000", ..., AT_SYMLINK_NOFOLLOW) =
-1 ENOENT
EXPECTED RESULT
Trashing a file should only need the trash directory of the filesystem
the file lives on. An unrelated, unresponsive mount should not delay or
block the operation.
ADDITIONAL INFORMATION
- The same scan also stats every snap loop mount (60+ paths here). That
is cheap locally, but shows how broad the scan is.
- Bug 467569 ("Move to trash should not wake up hdd") is the same root
cause with a milder symptom, and comment 1 there already points at the
scan in trashimpl.cpp. This report is about the network-mount case,
where the cost is not a spinning disk but a multi-second block.
- Possible directions: resolve the target filesystem's trash lazily on
the move path instead of scanning all mounts up front, and/or skip
mounts that are not currently responsive (or scan them out of band).
SOFTWARE/OS VERSIONS
Operating System: Ubuntu 26.04 LTS
KDE Frameworks: kio6 6.24.0
KDE Plasma: 6.6.5
Dolphin: 25.12.3
Kernel: 7.0.0-30-generic
Mounts: cifs vers=3.1.1 and vers=2.0, soft, actimeo=60
--
You are receiving this mail because:
You are watching all bug changes.
