Bug#624507: #624507 - Started looping and continuously rewriting metadata file - Debian Bug report logs
FYI, upstream [1] provides a series of patches now which are addressing the problem and should fix it both for remote and local filesystems which can be affected under certain circumstances as well. The developer is asking everyone who was affected, especially people deploying GNOME in a large environment to test the patch set. It might be worth to apply the patches to gvfs and have the fixed package included in a future point update of Debian Wheezy provided that the proposed patches work. We are going to drop Joss' patch 06_metadata_nfs.patch for some of our Debian Wheezy workstations on our network and install a test package with the patches provided by upstream to verify the patches work. If you can, please help testing, too. Cheers, Adrian [1] https://bugzilla.gnome.org/show_bug.cgi?id=637095 -- .''`. 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: #624507 - Started looping and continuously rewriting metadata file - Debian Bug report logs
Indeed that looping behaviour is not bound to occur only on remote file systems, but it is caused by the current version of the database file (like home) not referring to the redo log (like home-01234567.log) that is currently opened by the gvfsd (because it was referred to by the database at the time gvfsd opened the database). The usual reason for this mismatch is that the database has been replaced by a different version referring a different redo log file, but it could be due to data corruption, too. As long as the data base (and the redo log) is only used on a single system, the kernel (mostly?) ensures that once a redo log has been rotated into the data base, the this redo log is rotated-Bit is also seen by all other processes using the same redo log. This is why the bug usually does not appear in the single-system setup. There at least two different possible scenarios, how the mismatch could arise on a local file system, too: a) The local file system is exported, and the log has been rotated by a remote machine. b) The gvfs-metadata database directory has been restored from a backup while gvfsd-metadata was running. The temporary fix of disabling the metadata recording on remote file systems would help in scenario a, but not in scenario b. Regards, Michael Karcher -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#624507: #624507 - Started looping and continuously rewriting metadata file - Debian Bug report logs
Le mercredi 06 février 2013 à 20:03 +0100, Michael Karcher a écrit : There at least two different possible scenarios, how the mismatch could arise on a local file system, too: a) The local file system is exported, and the log has been rotated by a remote machine. b) The gvfs-metadata database directory has been restored from a backup while gvfsd-metadata was running. The temporary fix of disabling the metadata recording on remote file systems would help in scenario a, but not in scenario b. Indeed scenario A should not happen anymore. Scenario B is PEBKAC, so I don’t think we should care. Cheers, -- .''`. Josselin Mouette : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
