Ubuntu
gvfs package

gvfsd-trash causing high CPU-load when try to empty trash with thousands of files

Bug #1558768 reported by Jan Herold on 2016-03-17

This bug affects 8 people

Affects		Status	Importance	Assigned to	Milestone
	gvfs (Ubuntu)	Confirmed	High	Unassigned

Bug Description

- Ubuntu 16.04 (Xenial Xerus) Daily Build
- AMD64
- Unity

Steps to reproduce:
- a folder with thousands of files (here about 15000 files with a overall size of 1.5 GB)
- delete files to trash
- right-click at the trash icon
- click empty trash

A dialog "Dateioperationen" shows "vorbereiten" (it's German, I think in English the dialog has the title "file operations" and shows the text "prepare").

This happens at this point:
- the dialog remains unchanged
- the process gvfsd-trash consumes up to 75% CPU, see output of top

After 30 minutes of waiting for any reaction I killed the process. The trash still contains all the files.

jan@janvm160464:~$ top

top - 20:17:24 up 31 min, 1 user, load average: 1,94, 1,97, 1,68
Tasks: 244 gesamt, 5 laufend, 239 schlafend, 0 gestoppt, 0 Zombie
%CPU(s): 85,1 be, 14,6 sy, 0,0 ni, 0,0 un, 0,0 wa, 0,0 hi, 0,3 si, 0,0 st
KiB Spch : 4037984 gesamt, 2142152 frei, 900784 belegt, 995048 Puff/Cache
KiB Swap: 0 gesamt, 0 frei, 0 belegt. 3028940 verfü Spch

  PID USER PR NI VIRT RES SHR S %CPU %MEM ZEIT+ BEFEHL
1760 jan 20 0 454696 24448 7840 R 69,1 0,6 20:05.18 gvfsd-trash
1690 jan 20 0 781012 71096 36440 S 12,0 1,8 6:13.42 nautilus
2649 jan 20 0 660088 41700 30328 S 10,3 1,0 0:04.29 gedit
  315 root 20 0 32236 2936 2500 R 3,3 0,1 1:06.21 systemd-jou+
  825 root 20 0 383184 77448 31492 S 1,3 1,9 0:15.84 Xorg
1543 jan 20 0 1254876 189468 65780 S 1,3 4,7 0:19.38 compiz
  641 syslog 20 0 256380 3364 2684 S 1,0 0,1 0:16.81 rsyslogd
1521 jan 20 0 567508 32776 25756 S 0,7 0,8 0:01.16 unity-panel+
1448 jan 20 0 39728 316 12 S 0,3 0,0 0:00.13 upstart-dbu+
2258 root 20 0 0 0 0 S 0,3 0,0 0:00.23 kworker/u12+
2695 jan 20 0 48912 3868 3136 R 0,3 0,1 0:00.01 top
    1 root 20 0 119720 5664 3780 S 0,0 0,1 0:02.72 systemd
    2 root 20 0 0 0 0 S 0,0 0,0 0:00.00 kthreadd
    3 root 20 0 0 0 0 R 0,0 0,0 0:01.45 ksoftirqd/0
    5 root 0 -20 0 0 0 S 0,0 0,0 0:00.00 kworker/0:0H
    7 root 20 0 0 0 0 R 0,0 0,0 0:06.15 rcu_sched
    8 root 20 0 0 0 0 S 0,0 0,0 0:00.00 rcu_bh

Tags:

Revision history for this message

Jan Herold (yzle) wrote on 2016-03-17:

top.png Edit (109.6 KiB, image/png)

Revision history for this message

Ubuntu Foundations Team Bug Bot (crichton) wrote on 2016-03-17:

Thank you for taking the time to report this bug and helping to make Ubuntu better. It seems that your bug report is not filed about a specific source package though, rather it is just filed against Ubuntu in general. It is important that bug reports be filed about source packages so that people interested in the package can find the bugs about it. You can find some hints about determining what package your bug might be about at https://wiki.ubuntu.com/Bugs/FindRightPackage. You might also ask for help in the #ubuntu-bugs irc channel on Freenode.

To change the source package that this bug is filed about visit https://bugs.launchpad.net/ubuntu/+bug/1558768/+editstatus and add the package name in the text box next to the word Package.

[This is an automated message. I apologize if it reached you inappropriately; please just reply to this message indicating so.]

tags:

added: bot-comment

Jan Herold (yzle) on 2016-03-17

affects:

ubuntu → gvfs (Ubuntu)

Revision history for this message

Mark (mark-delta-echo) wrote on 2016-09-28:

This error persist until now.
Ubuntu 16.04
kernel: 4.4.0-38-generic #57-Ubuntu SMP Tue Sep 6 15:42:33 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

In my case I reproduced the error by sending hundreds of thumbnails to the trash with the same effect.

Revision history for this message

Launchpad Janitor (janitor) wrote on 2016-11-14:

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in gvfs (Ubuntu):
status:	New → Confirmed

Revision history for this message

bb (vancouverbluesea) wrote on 2016-11-14:

This persists - big nuisance.
1. Create an empty folder
2. Execute "touch bspl{0001..7000}.c" (simply crates 7000 empty files)
3. Move the files to trash
The system consumed 8GB RAM and 8GB SWAP - heavy usage of CPU - you can monitor with top
If I am to wait a few min it will resolve and both RAM and SWAP would go down to 1.5GB
If I want to get out of it somehow - I can killall gvfsd-trash and killall nautilus
Then go to ~/.local/share/Trash/files$ and empty the content and also
go to ~/.local/share/Trash/info$ and empty the content

I use Darktable (beautiful RAW image manipulation program). Often I have to delete thousands of files that take a few GB of space. Having a trash is desirable feature as it gives safety net for few days.
However this behaviour (consuming all the resources of the system) is more than an inconvenience - it makes the trash unusable.

If somebody knows how to workaround this please advise.

Revision history for this message

Mantas Kriaučiūnas (mantas) wrote on 2018-10-19:

I also noticed, that gvfsd-trash fills up memory (uses about 1 GB) if Trash contains thousands of files, see bug #1798828

Revision history for this message

Dan Dascalescu (ddascalescu+launchpad) wrote on 2019-03-01:

My Trash is empty (see screenshot), yet this process is chewing an entire CPU core. Edit (40.4 KiB, image/png)

Still seeing this with an empty Trash on Ubuntu 18.

Revision history for this message

Bradley Pearce (blitmaps) wrote on 2020-07-10:

I am on Ubuntu 20.04 with 64GB RAM and Threadripper 32 Core, when emptying trash, with 32K files (the Flikr 30K dataset), a number of gvfsd-trash threads are spawned and the Gnome desktop freezes.

To determine it was gvfsd-trash, I switched to another tty, logged in to console, and killed the process using htop. This restored desktop functionality.

I don't know what to look for in the logs, but I can reliably reproduce the behaviour.

Steps:

1. download the flickr 30K dataset : https://www.kaggle.com/hsankesara/flickr-image-dataset
2. Extract and then open the folder containing the files (this will take about 22s in Nautilus on my workstation, as an aside this operation takes >2s in Windows Explorer),
3. Select All (This takes about 9 seconds, as an aside, this operation takes >.5 seconds in Windows Explorer).
4. Delete files (This takes a few minutes)
5. Empty trash and watch Gnome Shell and all applications hang like me??

Revision history for this message

Humphrey van Polanen Petel (hpvpp) wrote on 2020-08-01:

copied from Bug 1798828
--
Ubuntu LTS 16.04.6

118K files in trash
gvfs-trash consumes both CPUs and 100% of available memory

"empty trash" goes into prepare phase, but nothing appears to happen, presumably because of the large number of files, so I closed the window by clicking the <x>

rm -rf ~/.local/share/Trash/*

nautilus window on trash:/// goes dark for a long time, but eventually comes back to show Trash to be empty

opening the Trash icon (on the on the launch bar) shows it to be empty and both <restore> and <empty> buttons are greyed out, but the Trash icon still shows 'filled'

Revision history for this message

Sebastien Bacher (seb128) wrote on 2020-08-03:

#10

The issue is a bit similar to https://gitlab.gnome.org/GNOME/gvfs/-/issues/416 upstream, if the shell is hanging it's probably worth reporting a new bug on gitlab.gnome.org