Binary package hint: nautilus
I have been getting delays of 30-60 seconds when nautilus copies data on an NTFS filesystem in a 1.5 TB My Book external USB disk from Western Digital. I was able to see the process that has 100% of the CPU and causes spinners in my Nautilus Windows until it finishes. It is gvfsd-metadata, for which I have no man page.
Today, I closed an earlier bug thinking that the problem had resolved itself as I had nominal functionality with nautilus then. I noticed that the problem returned and looked at running processes with top (1) to see what process appeared and what it was using when it ran.
I don't know what gvfsd-metadata does or how important it is, but it seems to be the hog process. As soon as it exits I get the FM back. It appears whenever I move (drag) files from one dir to another. Another bug where I had long delays moving a 1.0 GB dir from the boot drive to this external drive, may be the same problem.
ProblemType: Bug
DistroRelease: Ubuntu 10.10
Package: nautilus 1:2.32.0-0ubuntu1.3
ProcVersionSignature: Ubuntu 2.6.35-25.44-generic 2.6.35.10
Uname: Linux 2.6.35-25-generic i686
Architecture: i386
Date: Wed Feb 9 23:09:42 2011
ExecutablePath: /usr/bin/nautilus
ProcEnviron:
LANG=en_US.utf8
SHELL=/bin/bash
SourcePackage: nautilus
I think that I know how to cause this at will. It is easy to do if you are
impatient with a slow disk or slow driver for a filesystem. Just move a dir
before nautalis is done with it.
Of course the clue to what is really happening is to deal with what
gvfsd-metadata depends on. If I don't get the problem if I am just moving
files from a shell prompt, but I'm waiting for nautilus to do thumbnails of
images, but it lets me go off and do something to the filesystem state that
confuses the gvfsd-metadata process, that will lead to corruption of the
cache, which I assume is a heap of C or C++ structs, and every time it comes
back and tries to navigate that it will get hung. I don't know if some locks
are needed in the code to prevent another file operation from touching the
cache wile one is still in progress, just a guess. Just clobbering the cache
is a work around, but does it have any risks, and if so is there a better
way to prevent the corruption? Should an attempt to navigate away from a dir
that nautalis is busy generating meadata, stop that gracefully?
On Mon, Aug 1, 2011 at 11:40 AM, Launchpad Bug Tracker <
<email address hidden>> wrote:
> ** Changed in: nautilus (Ubuntu)
> Status: New => Confirmed
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https:/
>
> Title:
> gvfsd-metadata process pegs CPU while nautilus waits
>
> Status in “nautilus” package in Ubuntu:
> Confirmed
>
> Bug description:
> Binary package hint: nautilus
>
> I have been getting delays of 30-60 seconds when nautilus copies data
> on an NTFS filesystem in a 1.5 TB My Book external USB disk from
> Western Digital. I was able to see the process that has 100% of the
> CPU and causes spinners in my Nautilus Windows until it finishes. It
> is gvfsd-metadata, for which I have no man page.
>
> Today, I closed an earlier bug thinking that the problem had resolved
> itself as I had nominal functionality with nautilus then. I noticed
> that the problem returned and looked at running processes with top (1)
> to see what process appeared and what it was using when it ran.
>
> I don't know what gvfsd-metadata does or how important it is, but it
> seems to be the hog process. As soon as it exits I get the FM back. It
> appears whenever I move (drag) files from one dir to another. Another
> bug where I had long delays moving a 1.0 GB dir from the boot drive to
> this external drive, may be the same problem.
>
> ProblemType: Bug
> DistroRelease: Ubuntu 10.10
> Package: nautilus 1:2.32.0-0ubuntu1.3
> ProcVersionSign
> Uname: Linux 2.6.35-25-generic i686
> Architecture: i386
> Date: Wed Feb 9 23:09:42 2011
> ExecutablePath: /usr/bin/nautilus
> ProcEnviron:
> LANG=en_US.utf8
> SHELL=/bin/bash
> SourcePackage: nautilus
>
> To manage notifications about this bug go to:
>
> https:/
>