Bug#624507: #624507 - Started looping and continuously rewriting metadata file - Debian Bug report logs

[Michael Karcher]

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