Stephen Browne wrote: > Niall implemeted a patch that always trashed to the user's homedir. > This can have its own problems (moving files across file systems) but as > most users will be trashing files from their own home dir we thought it > was better than having all these stats bogging down the system and > stalling nautilus startup if there was a stale nfs mount. > I don't know if gvfsd-trash got the same behaviour, but Alex Larsson also made a subsequent fix to gnome-vfs that serialised trash searches by reusing the child process to scan for trash instead of creating a seperate child for each mount point. If I remember right it was actually a grandchild process that did the stat(). That way if the stat() blocked, the nautilus process wouldn't get wedged. If gvfs-trash wasn't implemented the same way, it would probably make an improvement to do so.
Niall. > Stephen. > > > On Thu, 2008-04-03 at 11:55 +0200, Alvaro Lopez Ortega wrote: > >> Hi Lin, >> >> I know we had to fix the same issue with gnome-vfs quite a long time >> ago. >> >> Does somebody remember the solution we came up with? (Niall? Stephen? >> As far as I remember you fixed it). >> >> >> On 31 Mar 2008, at 09:57, Lin Ma wrote: >> >> >>> I found the recent builds -- Vermillion 85, 86 there is a serious >>> issue >>> about gvfsd-trash, it will recursively scan (stat(2)) all TRASH >>> directories on all mounted topdirs (spec is located at >>> http://www.ramendik.ru/docs/trashspec.html). Unfortunately in our swan >>> most auto-mount path are the ZFS filesystems which usually represent a >>> couple of layered mount points in /etc/mnttab. While gvfsd-trash will >>> try forking extra processes to scan those mount points and trigger >>> more >>> ZFS mount points that finally created hundreds of gvfsd-trash >>> processes >>> and slow down the system. >>> >>> I'm not sure if anyone found this problem. My investigation is >>> gvfsd-trash processes are communicating with pipes, in my box, the >>> opened pipes seem broken and are ignored by gvfsd-trash. Maybe a >>> SIGPIPE >>> detection is enough for the fix or maybe the TRASH spec need be >>> reworked. >>> >>> This should be a ZFS special case and should be definitely a stopper >>> if >>> it is a common case. >>> >>> Thanks, >>> lin >>> >>> -- >>> x82120 / +86 10 82618200 >>> >>> _______________________________________________ >>> desktop-discuss mailing list >>> desktop-discuss at opensolaris.org >>> >> -- >> Greetings, alo. >> >> > >
