Bug #1308

hammer: stat returns wrong time when using tids

Added by corecode about 5 years ago. Updated almost 5 years ago.

Status:ClosedStart date:
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:-
Target version:-

Description

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.

History

#1 Updated by dillon about 5 years ago

:When stat'ing a file with tid, hammer seems to always return the "first" ti=
:me
:for mtime, not the real mtime. However undo -i can retrieve this time, so =
:it
: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.

-Matt

#2 Updated by corecode about 5 years ago

Ah now I see, it always reports to ctime of the inode. I suppose we don't
keep track of mtimes then?

cheers
simon

#3 Updated by dillon about 5 years ago

:Ah now I see, it always reports to ctime of the inode. I suppose we don'=
:t=20
:keep track of mtimes then?
:
:cheers
: simon

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).

-Matt
Matthew Dillon
<>

#4 Updated by corecode almost 5 years ago

seems to be the way it is designed.

Also available in: Atom PDF