Bug#624507: closed by Josselin Mouette <joss at debian.org> (Bug#624507: fixed in gvfs 1.12.3-4)

[Josh Triplett]

On Wed, Feb 06, 2013 at 09:10:07AM +0100, John Paul Adrian Glaubitz wrote:
> > Quite possibly a good idea, but note that the my original report
> > occurred with a local filesystem, not a remote filesystem.
> 
> Are you absolutely sure that it happened on a local filesystem in
> your case and not on a home directory mounted over NFS?
> 
> I'm having a hard time to believe that you observed the behavior on
> a local filesystem since it is triggered by concurrent access
> problems of two instances of gvfsd-metadata running on two
> individual machines having access to the same filesystem over NFS.
> 
> The problem will not occur with two instances of the daemon running
> on the same machine, i.e. when accessing a local filesystem, since
> the kernel will perform concurrent accesses to the database with
> memory mapping.

I observed the bug on my laptop, with a local home directory (ext4 on
LVM on dm-crypt on internal Intel SSD on SATA), and no remote mounts of
any kind.

> Please see the detailed analysis by Michael Karcher on this issue
> where he explains why the bug only occurs when accessing the
> database over remote filesystems [1].

The comment you link to seems to suggest a narrow but existent race
window even on a local system: "As long as there are multiple instances
running on one host, all instances share the same mmap() view of the
redo log, so their entries are properly merged as long as no two writes
happen at the same time. The time window for race condition problems is
quite small, although the problem is probably provocable when stressing
gvfsd-metadata in concurrent instances. The rwlock in the code won't
help between different processes, although it seems to do the job for a
single process, even if it runs in multiple threads."

Though I don't have any reason to believe that two gvfs-metadata
instances ran on my machine simultaneously, either.  But, for instance,
I could believe that my laptop had previously lost power or kernel
panic'd at exactly the wrong time.  That wouldn't make it any less a bug
for gvfs-metadata to loop, though.

> If you are really seeing this issue with local filesystems, you are
> really encouraged to file a new bug report.

I certainly saw the issue that prompted the original report and strace
on a local filesystem.  I've already filed that bug, though. :)

> On a sidenote, Red Hat has acknowledged this bug now in an internal
> bug report and is working on a proper fix now after an important
> customer complained seeing this issue on their machines.

That makes me feel ever so special. ;)

- Josh Triplett