Bug#624507: closed by Josselin Mouette j...@debian.org (Bug#624507: fixed in gvfs 1.12.3-4)
Hi Josh, 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. 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]. If you are really seeing this issue with local filesystems, you are really encouraged to file a new bug report. 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. Cheers, Adrian [1] https://bugzilla.redhat.com/show_bug.cgi?id=561904#c30 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#624507: closed by Josselin Mouette j...@debian.org (Bug#624507: fixed in gvfs 1.12.3-4)
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 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#624507: closed by Josselin Mouette j...@debian.org (Bug#624507: fixed in gvfs 1.12.3-4)
On 05.02.2013 17:12, Josh Triplett wrote: On Tue, Feb 05, 2013 at 03:06:06PM +, Debian Bug Tracking System wrote: gvfs (1.12.3-4) unstable; urgency=low . * 06_metadata_nfs.patch: new patch. Disable gvfsd-metadata entirely on remote filesystems. It is better to miss functionality than to hammer the server. Closes: #624507. Quite possibly a good idea, but note that the my original report occurred with a local filesystem, not a remote filesystem. Yeah, I would consider this more of a workaround then a proper fix. It's simply much easier to trigger this issue on a system with remote home then on a local system. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#624507: closed by Josselin Mouette j...@debian.org (Bug#624507: fixed in gvfs 1.12.3-4)
On Tue, Feb 05, 2013 at 03:06:06PM +, Debian Bug Tracking System wrote: gvfs (1.12.3-4) unstable; urgency=low . * 06_metadata_nfs.patch: new patch. Disable gvfsd-metadata entirely on remote filesystems. It is better to miss functionality than to hammer the server. Closes: #624507. Quite possibly a good idea, but note that the my original report occurred with a local filesystem, not a remote filesystem. - Josh Triplett -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
