[dolphin] [Bug 386460] Trashing is slow when trash size is limited
https://bugs.kde.org/show_bug.cgi?id=386460 Claudius Ellsel changed: What|Removed |Added CC||claudius.ell...@live.de --- Comment #10 from Claudius Ellsel --- Just for the record, this looks like a regression for this old bug: https://bugs.kde.org/show_bug.cgi?id=179348 -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 386460] Trashing is slow when trash size is limited
https://bugs.kde.org/show_bug.cgi?id=386460 Claudius Ellsel changed: What|Removed |Added See Also||https://bugs.kde.org/show_b ||ug.cgi?id=179348 -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 386460] Trashing is slow when trash size is limited
https://bugs.kde.org/show_bug.cgi?id=386460 Nate Graham changed: What|Removed |Added Version Fixed In||5.51 Status|CONFIRMED |RESOLVED Resolution|--- |FIXED Latest Commit||https://cgit.kde.org/kio.gi ||t/commit/?id=9d682612de4691 ||a13daa69d02816d23b6a77a285 --- Comment #9 from Nate Graham --- author Alexander Volkov 2018-09-06 21:42:57 (GMT) committer Alexander Volkov 2018-09-06 21:43:26 (GMT) commit 9d682612de4691a13daa69d02816d23b6a77a285 (patch) tree33db7bb2252fd83ce8849aa8551a97543cd10710 parent 820f622e86bb0b7d44a39a3f90f84c99736b30c7 (diff) trash: Fix directorysizes cache parsing Summary: Entries in this file have the following format: [size] [mtime] [percent-encoded-directory-name] , and TrashSizeCache::add() writes them correctly, but TrashSizeCache::calculateSize() reads [mtime] as [size] and vice versa. Reviewers: #frameworks, dfaure Reviewed By: dfaure Subscribers: kde-frameworks-devel Tags: #frameworks Differential Revision: https://phabricator.kde.org/D15317 -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 386460] Trashing is slow when trash size is limited
https://bugs.kde.org/show_bug.cgi?id=386460 Alexander Volkov changed: What|Removed |Added CC||a.vol...@rusbitech.ru --- Comment #8 from Alexander Volkov --- Try KIO 5.51. -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 386460] Trashing is slow when trash size is limited
https://bugs.kde.org/show_bug.cgi?id=386460 --- Comment #7 from Wyatt Childers --- (In reply to Alexander Meshcheryakov from comment #4) > 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.
[dolphin] [Bug 386460] Trashing is slow when trash size is limited
https://bugs.kde.org/show_bug.cgi?id=386460 --- Comment #6 from Huon --- (In reply to Huon from comment #5) > First deletion: ~20s Sorry for spam, but this should read ~10s. -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 386460] Trashing is slow when trash size is limited
https://bugs.kde.org/show_bug.cgi?id=386460 --- Comment #5 from Huon --- > 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.
[dolphin] [Bug 386460] Trashing is slow when trash size is limited
https://bugs.kde.org/show_bug.cgi?id=386460 Alexander Meshcheryakov changed: What|Removed |Added CC||alexander@gmail.com --- Comment #4 from 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? -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 386460] Trashing is slow when trash size is limited
https://bugs.kde.org/show_bug.cgi?id=386460 Huon changed: What|Removed |Added Ever confirmed|0 |1 Version|17.08.2 |17.12.2 Status|UNCONFIRMED |CONFIRMED --- Comment #3 from Huon --- 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.
[dolphin] [Bug 386460] Trashing is slow when trash size is limited
https://bugs.kde.org/show_bug.cgi?id=386460 Huon changed: What|Removed |Added CC||h...@plonq.org --- Comment #2 from Huon --- 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.
[dolphin] [Bug 386460] Trashing is slow when trash size is limited
https://bugs.kde.org/show_bug.cgi?id=386460 Nate Graham changed: What|Removed |Added CC||pointedst...@zoho.com -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 386460] Trashing is slow when trash size is limited
https://bugs.kde.org/show_bug.cgi?id=386460 --- Comment #1 from Wyatt Childers --- (In reply to Wyatt Childers from comment #0) > 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. 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.
