hammer: stat returns wrong time when using tids
When stat'ing a file with tid, hammer seems to always return the "first" time
for mtime, not the real mtime. However undo -i can retrieve this time, so it
possibly isn't lost.
How to reproduce:
touch foo2 && fsync foo2 && sleep 5 && echo foo >> foo2 && fsync foo2 && sleep 5
&& echo foo2 >> foo2 && fsync foo2
then undo -i and stat any given foo2@@0x..., you'll always see the initial time,
except if you use tid -1.
#1 Updated by dillon over 9 years ago
:When stat'ing a file with tid, hammer seems to always return the "first" ti=
:for mtime, not the real mtime. However undo -i can retrieve this time, so =
:possibly isn't lost.
Note that the fixed mtime/atime for files accessed via a TID is to
ensure that snapshots remain consistent. Otherwise if you do something
such as tar up a snapshot and pipe it to md5, and then do it again
later, you will get a different result.
We may be able to do some refinement there, but whatever is returned
by the snapshot has to be returned every time the snapshot is accessed.
#3 Updated by dillon over 9 years ago
:Ah now I see, it always reports to ctime of the inode. I suppose we don'=
:keep track of mtimes then?
mtime and atime are updated in-place, without rolling a new inode
record, so a snapshot will not snapshot either field unless some
other action (e.g. like a file append, chmod, chown, etc) rolls a
new inode record after the snapshot was made.
Because of this the snapshot stat code always reports the ctime in
the atime and mtime fields to guarantee consistency.
It is possible to change this behavior, but probably not desirable
since it could very well result in a large number of inode records
getting rolled for no good reason (particularly for atime updates).