Am 17.04.2014 23:29, schrieb Oliver O.:
Conclusions:
The sequence of events seems to be:
1. The file was changed with generation 193090.
2. The snapshot for backup (@home-2014-04-16) was taken (generation
194551).
3. As the backup was reading from the snapshot, it was seeing stale
data (MyFile still at generation 36067).
This conclusion was wrong:
Rdiff-backup never really considered the modified Excel file for backup,
as its file modification time did not indicate that the file was newer
than the last backup. So rdiff-backup always took the file copy already
available in the previous backup.
What breaks the incremental backup mechanism is Excel modifying a file,
then changing its modification timestamp back to its original value (see
comment 10 at https://bugzilla.samba.org/show_bug.cgi?id=1601#c10).
4. As the backup comparison was reading from the snapshot, is was
seeing more recent data, causing a discrepancy with the stale data
just backed up.
The discrepancy between the file's modified contents were discovered
because the comparison was content-based (MD5 checksums) and compared
every file regardless of modification dates.
It seems that the snapshot needed some time to become stable for
reading. From a file system user's point of view, I'd expect a
snapshot to be atomic and stable at any time. Maybe some kind of
caching problem here?
Maybe it's time to file a bug report, but first: suggestions and ideas
appreciated.
Result: False alarm - this is definitely not a Btrfs problem. In this
case snapshot behavior was as expected: atomic and stable.
Sorry for any irritation.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
