Discussion:
[dolphin] [Bug 386460] New: Trashing is slow when trash size is limited
(too old to reply)
Wyatt Childers
2017-11-02 14:01:30 UTC
Permalink
Raw Message
https://bugs.kde.org/show_bug.cgi?id=386460

Bug ID: 386460
Summary: Trashing is slow when trash size is limited
Product: dolphin
Version: 17.08.2
Platform: Neon Packages
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: NOR
Component: general
Assignee: dolphin-bugs-***@kde.org
Reporter: ***@nearce.com
CC: ***@kde.org
Target Milestone: ---

Currently dolphin's trash system feels incredibly sluggish by default on many
distributions. I feel this has a negative impact on a lot of new users -- and
potentially unknowing experienced users -- in regards to their feeling about
dolphin and KDE in general.

I think this situation could be remedied a couple of different ways:
- Switch defaults so that dolphin operates on a 30 day time frame cleanup,
rather than a disk %
- Change the limiting system to be handed by a background job; so effectively
when you delete a file, it would be immediately moved, but then in the
background, something would be tasked with cleanup the necessary amount of disk
space from the trash soon after. This would allow the user to get instant
feedback, and the enforcement of the disk space limit would then happen
seamlessly in the background, without any impact to user experience.
--
You are receiving this mail because:
You are watching all bug changes.
Wyatt Childers
2017-11-02 14:03:47 UTC
Permalink
Raw Message
https://bugs.kde.org/show_bug.cgi?id=386460

--- Comment #1 from Wyatt Childers <***@nearce.com> ---
(In reply to Wyatt Childers from comment #0)
Post by Wyatt Childers
Currently dolphin's trash system feels incredibly sluggish by default on
many distributions. I feel this has a negative impact on a lot of new users
-- and potentially unknowing experienced users -- in regards to their
feeling about dolphin and KDE in general.
- Switch defaults so that dolphin operates on a 30 day time frame cleanup,
rather than a disk %
- Change the limiting system to be handed by a background job; so
effectively when you delete a file, it would be immediately moved, but then
in the background, something would be tasked with cleanup the necessary
amount of disk space from the trash soon after. This would allow the user to
get instant feedback, and the enforcement of the disk space limit would then
happen seamlessly in the background, without any impact to user experience.
Actually upon further testing, it seems the time based trash enforcement is
subject to the same performance penalties, and could benefit from the proposed
changes to disk space limiting.
--
You are receiving this mail because:
You are watching all bug changes.
Nate Graham
2017-11-02 15:42:44 UTC
Permalink
Raw Message
https://bugs.kde.org/show_bug.cgi?id=386460

Nate Graham <***@zoho.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@zoho.com
--
You are receiving this mail because:
You are watching all bug changes.
Huon
2018-03-06 23:47:52 UTC
Permalink
Raw Message
https://bugs.kde.org/show_bug.cgi?id=386460

Huon <***@plonq.org> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@plonq.org

--- Comment #2 from Huon <***@plonq.org> ---
Oddly I've only just recently (last week or so) noticed trashing being slow -
1-2 seconds trashing small (<1MB) files. Removing the size limit in Dolphin's
settings fixes this making trashing instantaneous.
--
You are receiving this mail because:
You are watching all bug changes.
Huon
2018-03-06 23:50:34 UTC
Permalink
Raw Message
https://bugs.kde.org/show_bug.cgi?id=386460

Huon <***@plonq.org> changed:

What |Removed |Added
----------------------------------------------------------------------------
Ever confirmed|0 |1
Version|17.08.2 |17.12.2
Status|UNCONFIRMED |CONFIRMED

--- Comment #3 from Huon <***@plonq.org> ---
Confirmed in latest release (17.12.2) and also current master (18.03.70).
--
You are receiving this mail because:
You are watching all bug changes.
Alexander Meshcheryakov
2018-03-14 08:21:10 UTC
Permalink
Raw Message
https://bugs.kde.org/show_bug.cgi?id=386460

Alexander Meshcheryakov <***@gmail.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@gmail.com

--- Comment #4 from Alexander Meshcheryakov <***@gmail.com> ---
I noticed this too. In my case deleting files had several seconds delay, but
subsequent deletion was instantaneous. I suppose delay is caused by calculation
of current trash size to decide whether it needs cleaning before adding new
content. While trash contents listing is cached in OS, it takes way less time
to recalculate occupied space for next deletion, but once it gets squeezed out
of cache moving content to trash needs to reread disk content.

One more thing that corroborates this theory: recently calculation of occupied
space got broken in my system ( https://bugs.kde.org/show_bug.cgi?id=383324#c2
), now dolphin shows free space of trash equal to its size limit regardless of
contents. And now moving content to trash is always instantaneous for me.

If my assumption is correct, this bug should not be noticeable for users with
trash on SSD. My $HOME is located on HDD, so reading thousands of files/dirs of
trash listing from storage should take seconds.

Wyatt, Huon are your trash located on HDD or SSD?
--
You are receiving this mail because:
You are watching all bug changes.
Huon
2018-03-14 10:27:01 UTC
Permalink
Raw Message
https://bugs.kde.org/show_bug.cgi?id=386460
Post by Alexander Meshcheryakov
Wyatt, Huon are your trash located on HDD or SSD?
I am on an NVMe SSD. I just tested again:

First deletion: ~20s
Second deletion: ~2.5s

Apart from that, I think your theory is solid. Something about the calculation
of trash size, which gets cached, or skipped entirely if trash size limit is
disabled.

I had a quick look in Dolphin's code for where this might be happening, but
being unfamiliar with the code base I couldn't find it (perhaps it's in KF5
somewhere?)
--
You are receiving this mail because:
You are watching all bug changes.
Huon
2018-03-14 10:28:14 UTC
Permalink
Raw Message
https://bugs.kde.org/show_bug.cgi?id=386460

--- Comment #6 from Huon <***@plonq.org> ---
(In reply to Huon from comment #5)
Post by Huon
First deletion: ~20s
Sorry for spam, but this should read ~10s.
--
You are receiving this mail because:
You are watching all bug changes.
Wyatt Childers
2018-03-19 22:48:28 UTC
Permalink
Raw Message
https://bugs.kde.org/show_bug.cgi?id=386460

--- Comment #7 from Wyatt Childers <***@nearce.com> ---
(In reply to Alexander Meshcheryakov from comment #4)
Post by Alexander Meshcheryakov
I noticed this too. In my case deleting files had several seconds delay, but
subsequent deletion was instantaneous. I suppose delay is caused by
calculation of current trash size to decide whether it needs cleaning before
adding new content. While trash contents listing is cached in OS, it takes
way less time to recalculate occupied space for next deletion, but once it
gets squeezed out of cache moving content to trash needs to reread disk
content.
One more thing that corroborates this theory: recently calculation of
occupied space got broken in my system (
https://bugs.kde.org/show_bug.cgi?id=383324#c2 ), now dolphin shows free
space of trash equal to its size limit regardless of contents. And now
moving content to trash is always instantaneous for me.
If my assumption is correct, this bug should not be noticeable for users
with trash on SSD. My $HOME is located on HDD, so reading thousands of
files/dirs of trash listing from storage should take seconds.
Wyatt, Huon are your trash located on HDD or SSD?
BTRFS SSD here
--
You are receiving this mail because:
You are watching all bug changes.
Loading...