Bug #2056

HAMMER does not update file access time after read

Added by marino about 7 years ago. Updated over 5 years ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:


During the development of the upgrade of grep to version 2.7, it was observed
that the HAVE_WORKING_O_NOATIME value was defined as 0 for the i386 platform and
1 for the x86_64 platform. The i386 platform filesystem was UFS and the other
was configured with Hammer.

The grep configuration script uses standard gnu tests. The one used to derive
the O_NOATIME value is located at

After some testing, swildner confirmed that Hammer doesn't update the file
access time after data (more than 0 bytes) is read from a file. He believes
that this behavior is not simply a convention, but covered by a standard. Since
Hammer isn't exhibiting the expected behavior, it should be considered a bug.

Moreover, every gnu configure script that is run on a system with Hammer will
produce the wrong value for O_NOATIME support, and thus may cause unexpected
behavior when the software compiles.


#1 Updated by swildner about 7 years ago

It actually is in the standard, I just didn't find it directly:

"Upon successful completion, where nbyte is greater than 0, read() shall mark
for update the last data access timestamp of the file, and shall return the
number of bytes read."


#2 Updated by alexh almost 7 years ago

I'll take a look at implementing this, it should be pretty straight forward.


#3 Updated by alexh almost 7 years ago

The code is in hammer_vop_read:

* XXX only update the atime if we had to get the MP lock.
* XXX hack hack hack, fixme.
if (got_fstoken) {
if ((ip->flags & HAMMER_INODE_RO) == 0 &&
(ip->hmp->mp->mnt_flag & MNT_NOATIME) == 0) {
ip->ino_data.atime = trans.time;
hammer_modify_inode(&trans, ip, HAMMER_INODE_ATIME);
return (error);

It seems that the atime is only updated sometimes. This is horribly inconsistent
behaviour. Matt needs to look at this one, too. I've not the slightest clue why
such a hackish behaviour.


#4 Updated by dillon almost 7 years ago

I have committed a change to master to hopefully make atime updates more
consistent. The code that was in there was an attempt to optimize the
concurrency path for read()'s for the case where the buffer cache buffers are
already cached.

Please test.


#5 Updated by marino over 5 years ago

  • Status changed from New to Closed

Both hammer and UFS give the same result given the provided test (as would be expected).

Also available in: Atom PDF