atimes not updated over NFS

After upgrading an NFS server from kernel 2.6.12 to 2.6.23, the atime of files is not updated any more when clients read them :

  client$ ll -u --time-style +%Y-%m-%d_%H:%M:%S /nfsmnt/zz
  -rw-r--r-- 1 xxx xxx 0 2007-12-21_14:58:11 /nfsmnt/zz
  client$ md5sum /nfsmnt/zz
  d41d8cd98f00b204e9800998ecf8427e  /nfsmnt/zz
  client$ date +%Y-%m-%d_%H:%M:%S
  2007-12-21_15:00:28
  client$ ll -u --time-style +%Y-%m-%d_%H:%M:%S /nfsmnt/zz
  -rw-r--r-- 1 xxx xxx 0 2007-12-21_14:58:11 /nfsmnt/zz

Reading the file locally, i.e. on the NFS server, does update the atime :

  server$ ll -u --time-style +%Y-%m-%d_%H:%M:%S /nfsmnt/zz
  -rw-r--r-- 1 xxx xxx 0 2007-12-21_14:58:11 /nfsmnt/zz
  serveur$ md5sum /nfsmnt/zz
  d41d8cd98f00b204e9800998ecf8427e  /nfsmnt/zz
  serveur$ date +%Y-%m-%d_%H:%M:%S
  2007-12-21_15:04:00
  serveur$ ll -u --time-style +%Y-%m-%d_%H:%M:%S /nfsmnt/zz
  -rw-r--r-- 1 xxx xxx 0 2007-12-21_15:03:57 /nfsmnt/zz

/nfsmnt is mounted with options :
- server : rw,noexec,nosuid,nodev,nodiratime
- client : rw,user=root,nosuid,nodev,nodiratime,intr,rsize=8192,wsize=8192

Any ideas ?

Quoted 19 lines · Andre Majorel

After upgrading an NFS server from kernel 2.6.12 to 2.6.23, the atime of files is not updated any more when clients read them :
=20
client$ ll -u --time-style +%Y-%m-%d_%H:%M:%S /nfsmnt/zz -rw-r--r-- 1 xxx xxx 0 2007-12-21_14:58:11 /nfsmnt/zz client$ md5sum /nfsmnt/zz d41d8cd98f00b204e9800998ecf8427e /nfsmnt/zz
client$ date +%Y-%m-%d_%H:%M:%S
2007-12-21_15:00:28
client$ ll -u --time-style +%Y-%m-%d_%H:%M:%S /nfsmnt/zz -rw-r--r-- 1 xxx xxx 0 2007-12-21_14:58:11 /nfsmnt/zz
=20
Reading the file locally, i.e. on the NFS server, does update the atime :
=20
server$ ll -u --time-style +%Y-%m-%d_%H:%M:%S /nfsmnt/zz -rw-r--r-- 1 xxx xxx 0 2007-12-21_14:58:11 /nfsmnt/zz serveur$ md5sum /nfsmnt/zz d41d8cd98f00b204e9800998ecf8427e /nfsmnt/zz

Quoted 8 lines

serveur$ date +%Y-%m-%d_%H:%M:%S
2007-12-21_15:04:00
serveur$ ll -u --time-style +%Y-%m-%d_%H:%M:%S /nfsmnt/zz -rw-r--r-- 1 xxx xxx 0 2007-12-21_15:03:57 /nfsmnt/zz
=20
/nfsmnt is mounted with options :
- server : rw,noexec,nosuid,nodev,nodiratime
- client : rw,user=3Droot,nosuid,nodev,nodiratime,intr,rsize=3D8192=

Quoted 2 lines

=20
Any ideas ?

=20
The file is probably entirely in cache on the client. When this happe=

no READ rpc calls need to be made to the server and so the atime will not change either.

This has always been the case, BTW...

I'll take your word for it. However, let me assure you that atimes somehow used to work over NFS, even for files small enough to fit in the cache. Had they been broken, I would have known. I use Mutt.

Quoted 3 lines · Andre Majorel

I'll take your word for it. However, let me assure you that atimes somehow used to work over NFS, even for files small enough to fit in the cache. Had they been broken, I would have known. I use Mutt.

How would the server know to update the atime? If the file is in cache we don't READ.

Quoted 3 lines · Andre Majorel

I'll take your word for it. However, let me assure you that atimes somehow used to work over NFS, even for files small enough to fit in the cache. Had they been broken, I would have known. I use Mutt.

=20
How would the server know to update the atime? If the file is in cach=

we don't READ.

Quoted 6 lines · Trond Myklebust

Quoted 3 lines · Andre Majorel

I'll take your word for it. However, let me assure you that atimes somehow used to work over NFS, even for files small enough to fit in the cache. Had they been broken, I would have known. I use Mutt.

Quoted 2 lines

How would the server know to update the atime? If the file is in cache we don't READ.

You tell me. All I can tell you is that Mutt used to work so atimes were updated one way or another.

Quoted 7 lines · Andre Majorel

Quoted 6 lines · Trond Myklebust

Quoted 3 lines · Andre Majorel

I'll take your word for it. However, let me assure you that atimes somehow used to work over NFS, even for files small enough to fit in the cache. Had they been broken, I would have known. I use Mutt.

Quoted 5 lines

Quoted 2 lines

How would the server know to update the atime? If the file is in cache we don't READ.

You tell me. All I can tell you is that Mutt used to work so atimes were updated one way or another.

I think 2.6.22 introduced this regression. On 2.6.22.10, reading a file on NFS does not affect atime according to stat(), not on the client and not on the server. This breaks several programs.

Commands to reproduce this problem on the client:

	dd </dev/zero >testfile count=1
	ls -l --time=atime --full-time testfile
	sleep 2
	wc testfile
	ls -l --time=atime --full-time testfile
		(same atime, not good)

Quoted 18 lines · Frank van Maarseveen

Quoted 7 lines · Andre Majorel

Quoted 6 lines · Trond Myklebust

Quoted 3 lines · Andre Majorel

I'll take your word for it. However, let me assure you that atimes somehow used to work over NFS, even for files small enough to fit in the cache. Had they been broken, I would have known. I use Mutt.

Quoted 5 lines

Quoted 2 lines

How would the server know to update the atime? If the file is in cache we don't READ.

You tell me. All I can tell you is that Mutt used to work so atimes were updated one way or another.

I think 2.6.22 introduced this regression. On 2.6.22.10, reading a file on NFS does not affect atime according to stat(), not on the client and not on the server. This breaks several programs.

Quoted 8 lines

Commands to reproduce this problem on the client:

	dd </dev/zero >testfile count=1
	ls -l --time=atime --full-time testfile
	sleep 2
	wc testfile
	ls -l --time=atime --full-time testfile
		(same atime, not good)

Can you confirm that it does not change on the server? If so, then we need to look at the server for a fix. The client should only be mirroring the server's idea of the correct atime.

Quoted 29 lines · Trond Myklebust

Quoted 26 lines · Frank van Maarseveen

Quoted 7 lines · Andre Majorel

Quoted 6 lines · Trond Myklebust

Quoted 3 lines · Andre Majorel

I'll take your word for it. However, let me assure you that atimes somehow used to work over NFS, even for files small enough to fit in the cache. Had they been broken, I would have known. I use Mutt.

Quoted 5 lines

Quoted 2 lines

How would the server know to update the atime? If the file is in cache we don't READ.

You tell me. All I can tell you is that Mutt used to work so atimes were updated one way or another.

I think 2.6.22 introduced this regression. On 2.6.22.10, reading a file on NFS does not affect atime according to stat(), not on the client and not on the server. This breaks several programs.

Commands to reproduce this problem on the client:

	dd </dev/zero >testfile count=1
	ls -l --time=atime --full-time testfile
	sleep 2
	wc testfile
	ls -l --time=atime --full-time testfile
		(same atime, not good)

Quoted 3 lines

Can you confirm that it does not change on the server? If so, then we need to look at the server for a fix. The client should only be mirroring the server's idea of the correct atime.

It doesn't change on the server (2.6.23.12)

Quoted 13 lines

Quoted 12 lines

Quoted 8 lines

Commands to reproduce this problem on the client:

	dd </dev/zero >testfile count=1
	ls -l --time=atime --full-time testfile
	sleep 2
	wc testfile
	ls -l --time=atime --full-time testfile
		(same atime, not good)

Can you confirm that it does not change on the server? If so, then we need to look at the server for a fix. The client should only be mirroring the server's idea of the correct atime.

Quoted 1 line

It doesn't change on the server (2.6.23.12)

That still leaves open the question as to whether this is due to changes in the client that are causing it not to issue a read to the server when it would have before, or whether the server is just refusing to update the atime on read for some reason....

Quoted 13 lines · J. Bruce Fields

Quoted 13 lines

Quoted 12 lines

Quoted 8 lines

Commands to reproduce this problem on the client:

	dd </dev/zero >testfile count=1
	ls -l --time=atime --full-time testfile
	sleep 2
	wc testfile
	ls -l --time=atime --full-time testfile
		(same atime, not good)

Can you confirm that it does not change on the server? If so, then we need to look at the server for a fix. The client should only be mirroring the server's idea of the correct atime.

Quoted 6 lines

Quoted 1 line

It doesn't change on the server (2.6.23.12)

That still leaves open the question as to whether this is due to changes in the client that are causing it not to issue a read to the server when it would have before, or whether the server is just refusing to update the atime on read for some reason....

A script of the form

                ssh server 'dd </dev/zero >testfile count=1; ls -l --time=atime --full-time testfile'

cat testfile >/dev/null

                
                ssh server 'ls -l --time=atime --full-time testfile'
                ls -l --time=atime --full-time testfile

Quoted 15 lines · Trond Myklebust

Quoted 13 lines · J. Bruce Fields

Quoted 13 lines

Quoted 12 lines

Quoted 8 lines

Commands to reproduce this problem on the client:

	dd </dev/zero >testfile count=1
	ls -l --time=atime --full-time testfile
	sleep 2
	wc testfile
	ls -l --time=atime --full-time testfile
		(same atime, not good)

Can you confirm that it does not change on the server? If so, then we need to look at the server for a fix. The client should only be mirroring the server's idea of the correct atime.

Quoted 8 lines

Quoted 6 lines

Quoted 1 line

It doesn't change on the server (2.6.23.12)

That still leaves open the question as to whether this is due to changes in the client that are causing it not to issue a read to the server when it would have before, or whether the server is just refusing to update the atime on read for some reason....

A script of the form

"rm -f testfile" and at least one "touch ." in advance to get deterministic behavior.

Quoted 2 lines

                ssh server 'dd </dev/zero >testfile count=1; ls -l --time=atime --full-time testfile'

put a sleep 2 here.

Quoted 2 lines

cat testfile >/dev/null

put a sleep 2 here just in case we would race with something in flight

Quoted 4 lines

                
                ssh server 'ls -l --time=atime --full-time testfile'
                ls -l --time=atime --full-time testfile

I tried some kernels (same on client and server). There are three atimes after each experiment.

2.6.21.7:

	t
	t + 2
	t + 2

This seems to work but it doesn't: only the first "cat testfile" will update the atime. Subsequent cat commands will not update atime unless "cat" is executed on the server.

2.6.22.10:

	t
	t + 2
	t + 2

(same behavior)

2.6.23.12:
t
t
t

definately not good. "cat" on the server updates atime again.

Trying a different combination of kernels:

server 2.6.23.12, client 2.6.22.10:
t
t
t

server 2.6.22.10, client 2.6.23.12:

	t
	t + 2
	t + 2

so, there are 2 phenomena and one has been introduced with 2.6.23 on the server side. Filesystem on the server is ext3.

Signature · 1 line

Frank

Quoted 20 lines · Frank van Maarseveen

"rm -f testfile" and at least one "touch ." in advance to get deterministic behavior.

Quoted 2 lines

                ssh server 'dd </dev/zero >testfile count=1; ls -l --time=atime --full-time testfile'

put a sleep 2 here.

Quoted 2 lines

cat testfile >/dev/null

put a sleep 2 here just in case we would race with something in flight

Quoted 4 lines

                
                ssh server 'ls -l --time=atime --full-time testfile'
                ls -l --time=atime --full-time testfile

I tried some kernels (same on client and server). There are three atimes after each experiment.

Quoted 8 lines

2.6.21.7:

	t
	t + 2
	t + 2

This seems to work but it doesn't: only the first "cat testfile" will update the atime. Subsequent cat commands will not update atime unless "cat" is executed on the server.

I think that's just the expected result of client caching, so all you can do in that case is add "set check_mbox_size=yes" to your .muttrc or something.....

Quoted 6 lines

2.6.22.10:

	t
	t + 2
	t + 2

Quoted 8 lines

(same behavior)

2.6.23.12:
t
t
t

definately not good. "cat" on the server updates atime again.

Yes, that looks like a server bug, and this:...

Quoted 9 lines

Trying a different combination of kernels:

server 2.6.23.12, client 2.6.22.10:
t
t
t

Quoted 4 lines

server 2.6.22.10, client 2.6.23.12:

	t
	t + 2
	t + 2

...confirms that since the results appear to depend only on the server version, not on the client version.

Quoted 31 lines · bfields

Quoted 5 lines · Frank van Maarseveen

2.6.22.10:

	t
	t + 2
	t + 2

Quoted 8 lines

(same behavior)

2.6.23.12:
t
t
t

definately not good. "cat" on the server updates atime again.

Yes, that looks like a server bug, and this:...

Quoted 13 lines

Trying a different combination of kernels:

server 2.6.23.12, client 2.6.22.10:
t
t
t

server 2.6.22.10, client 2.6.23.12:

	t
	t + 2
	t + 2

Quoted 2 lines

...confirms that since the results appear to depend only on the server version, not on the client version.

And I can confirm this here on 2.6.24-rc8 (+ a few patches). Unfortunately, I don't have any suggestion better right now than bisecting....

Quoted 32 lines · bfields

Quoted 31 lines · bfields

Quoted 5 lines · Frank van Maarseveen

2.6.22.10:

	t
	t + 2
	t + 2

Quoted 8 lines

(same behavior)

2.6.23.12:
t
t
t

definately not good. "cat" on the server updates atime again.

Yes, that looks like a server bug, and this:...

Quoted 13 lines

Trying a different combination of kernels:

server 2.6.23.12, client 2.6.22.10:
t
t
t

server 2.6.22.10, client 2.6.23.12:

	t
	t + 2
	t + 2

Quoted 6 lines

Quoted 2 lines

...confirms that since the results appear to depend only on the server version, not on the client version.

And I can confirm this here on 2.6.24-rc8 (+ a few patches). Unfortunately, I don't have any suggestion better right now than bisecting....

It looks like this happened in the switch from sendfile to sparse.

Jens, any advice? What happened was nfsd reads stopped updating the atime after the following commit.

Quoted 33 lines · bfields

Quoted 32 lines · bfields

Quoted 31 lines · bfields

Quoted 5 lines · Frank van Maarseveen

2.6.22.10:

	t
	t + 2
	t + 2

Quoted 8 lines

(same behavior)

2.6.23.12:
t
t
t

definately not good. "cat" on the server updates atime again.

Yes, that looks like a server bug, and this:...

Quoted 13 lines

Trying a different combination of kernels:

server 2.6.23.12, client 2.6.22.10:
t
t
t

server 2.6.22.10, client 2.6.23.12:

	t
	t + 2
	t + 2

Quoted 8 lines

Quoted 6 lines

Quoted 2 lines

...confirms that since the results appear to depend only on the server version, not on the client version.

And I can confirm this here on 2.6.24-rc8 (+ a few patches). Unfortunately, I don't have any suggestion better right now than bisecting....

It looks like this happened in the switch from sendfile to sparse.

							     ^^^^^^
							err, splice

Quoted 2 lines

Jens, any advice? What happened was nfsd reads stopped updating the atime after the following commit.

Erm, sorry, wrong commit--it's the following one that touches nfsd, below.

Quoted 45 lines · J. Bruce Fields

Quoted 33 lines · bfields

Quoted 32 lines · bfields

Quoted 31 lines · bfields

Quoted 5 lines · Frank van Maarseveen

2.6.22.10:

	t
	t + 2
	t + 2

Quoted 8 lines

(same behavior)

2.6.23.12:
t
t
t

definately not good. "cat" on the server updates atime again.

Yes, that looks like a server bug, and this:...

Quoted 13 lines

Trying a different combination of kernels:

server 2.6.23.12, client 2.6.22.10:
t
t
t

server 2.6.22.10, client 2.6.23.12:

	t
	t + 2
	t + 2

Quoted 8 lines

Quoted 6 lines

Quoted 2 lines

...confirms that since the results appear to depend only on the server version, not on the client version.

And I can confirm this here on 2.6.24-rc8 (+ a few patches). Unfortunately, I don't have any suggestion better right now than bisecting....

It looks like this happened in the switch from sendfile to sparse.

							     ^^^^^^
							err, splice

Quoted 5 lines

Quoted 2 lines

Jens, any advice? What happened was nfsd reads stopped updating the atime after the following commit.

Erm, sorry, wrong commit--it's the following one that touches nfsd, below.

Probably because do_generic_mapping_read() does a file_accessed() on the input file. Does this fixup current -git?

fs/splice.c +3 -1

index 56b802b..c212fde 100644
@@ -1090,8 +1090,10 @@ long do_splice_direct(struct file *in, loff_t *ppos, struct file *out,
 	long ret;
 
 	ret = splice_direct_to_actor(in, &sd, direct_splice_actor);
-	if (ret > 0)
+	if (ret > 0) {
 		*ppos += ret;
+		file_accessed(in);
+	}
 
 	return ret;
 }

Signature · 2 lines

-- 
Jens Axboe

Quoted 49 lines · Jens Axboe

Quoted 48 lines · J. Bruce Fields

Quoted 33 lines · bfields

Quoted 32 lines · bfields

Quoted 31 lines · bfields

Quoted 5 lines · Frank van Maarseveen

2.6.22.10:

	t
	t + 2
	t + 2

Quoted 8 lines

(same behavior)

2.6.23.12:
t
t
t

definately not good. "cat" on the server updates atime again.

Yes, that looks like a server bug, and this:...

Quoted 13 lines

Trying a different combination of kernels:

server 2.6.23.12, client 2.6.22.10:
t
t
t

server 2.6.22.10, client 2.6.23.12:

	t
	t + 2
	t + 2

Quoted 8 lines

Quoted 6 lines

Quoted 2 lines

...confirms that since the results appear to depend only on the server version, not on the client version.

And I can confirm this here on 2.6.24-rc8 (+ a few patches). Unfortunately, I don't have any suggestion better right now than bisecting....

It looks like this happened in the switch from sendfile to sparse.

							     ^^^^^^
							err, splice

Quoted 2 lines

Jens, any advice? What happened was nfsd reads stopped updating the atime after the following commit.

Quoted 5 lines

Quoted 2 lines

Erm, sorry, wrong commit--it's the following one that touches nfsd, below.

Probably because do_generic_mapping_read() does a file_accessed() on the input file. Does this fixup current -git?

No, nfsd is calling splice_direct_to_actor(), not do_splice_direct().

Quoted 50 lines · J. Bruce Fields

Quoted 49 lines · Jens Axboe

Quoted 48 lines · J. Bruce Fields

Quoted 33 lines · bfields

Quoted 32 lines · bfields

Quoted 31 lines · bfields

Quoted 5 lines · Frank van Maarseveen

2.6.22.10:

	t
	t + 2
	t + 2

Quoted 8 lines

(same behavior)

2.6.23.12:
t
t
t

definately not good. "cat" on the server updates atime again.

Yes, that looks like a server bug, and this:...

Quoted 13 lines

Trying a different combination of kernels:

server 2.6.23.12, client 2.6.22.10:
t
t
t

server 2.6.22.10, client 2.6.23.12:

	t
	t + 2
	t + 2

Quoted 8 lines

Quoted 6 lines

Quoted 2 lines

...confirms that since the results appear to depend only on the server version, not on the client version.

And I can confirm this here on 2.6.24-rc8 (+ a few patches). Unfortunately, I don't have any suggestion better right now than bisecting....

It looks like this happened in the switch from sendfile to sparse.

							     ^^^^^^
							err, splice

Quoted 2 lines

Jens, any advice? What happened was nfsd reads stopped updating the atime after the following commit.

Quoted 7 lines

Quoted 5 lines

Quoted 2 lines

Erm, sorry, wrong commit--it's the following one that touches nfsd, below.

Probably because do_generic_mapping_read() does a file_accessed() on the input file. Does this fixup current -git?

No, nfsd is calling splice_direct_to_actor(), not do_splice_direct().

Ah doh, this instead then. Should work for both types.

fs/splice.c +0 -0

index 0a0b79b..504a096 100644

Quoted 75 lines · Jens Axboe

Quoted 50 lines · J. Bruce Fields

Quoted 49 lines · Jens Axboe

Quoted 48 lines · J. Bruce Fields

Quoted 33 lines · bfields

Quoted 32 lines · bfields

Quoted 31 lines · bfields

Quoted 5 lines · Frank van Maarseveen

2.6.22.10:

	t
	t + 2
	t + 2

Quoted 8 lines

(same behavior)

2.6.23.12:
t
t
t

definately not good. "cat" on the server updates atime again.

Yes, that looks like a server bug, and this:...

Quoted 13 lines

Trying a different combination of kernels:

server 2.6.23.12, client 2.6.22.10:
t
t
t

server 2.6.22.10, client 2.6.23.12:

	t
	t + 2
	t + 2

Quoted 8 lines

Quoted 6 lines

Quoted 2 lines

...confirms that since the results appear to depend only on the server version, not on the client version.

And I can confirm this here on 2.6.24-rc8 (+ a few patches). Unfortunately, I don't have any suggestion better right now than bisecting....

It looks like this happened in the switch from sendfile to sparse.

							     ^^^^^^
							err, splice

Quoted 2 lines

Jens, any advice? What happened was nfsd reads stopped updating the atime after the following commit.

Quoted 7 lines

Quoted 5 lines

Quoted 2 lines

Erm, sorry, wrong commit--it's the following one that touches nfsd, below.

Probably because do_generic_mapping_read() does a file_accessed() on the input file. Does this fixup current -git?

No, nfsd is calling splice_direct_to_actor(), not do_splice_direct().

Ah doh, this instead then. Should work for both types.

fs/splice.c +3 -1

index 0a0b79b..504a096 100644
@@ -1052,8 +1052,10 @@ out_release:
 	/*
 	 * If we transferred some data, return the number of bytes:
 	 */
-	if (bytes > 0)
+	if (bytes > 0) {
+		file_accessed(in);
 		return bytes;
+	}
 

fs/splice.c out_release: · line 1060

Quoted 1 line

fs/splice.c +0 -0

 	return ret;

Hm. It's still missing a case. I've confirmed that the following fixes the problem. (Or maybe it would be better to have them "goto" a common out with the file_accessed() check?)

Quoted 3 lines · J. Bruce Fields

Hm. It's still missing a case. I've confirmed that the following fixes the problem. (Or maybe it would be better to have them "goto" a common out with the file_accessed() check?)

Indeed it is, insert standard disclaimer here on the evil of multiple returns. So can we agree that this then fixes both cases?

fs/splice.c +7 -8

index 0a0b79b..1577a73 100644
@@ -1031,7 +1031,11 @@ ssize_t splice_direct_to_actor(struct file *in, struct splice_desc *sd,
 			goto out_release;
 	}
 
+done:
 	pipe->nrbufs = pipe->curbuf = 0;
+	if (bytes > 0)
+		file_accessed(in);
+
 	return bytes;
 
 out_release:

@@ -1047,16 +1051,11 @@ out_release:
 			buf->ops = NULL;
 		}
 	}
-	pipe->nrbufs = pipe->curbuf = 0;
-
-	/*
-	 * If we transferred some data, return the number of bytes:
-	 */
-	if (bytes > 0)
-		return bytes;
 
-	return ret;
+	if (!bytes)
+		bytes = ret;
 
+	goto done;
 }
 EXPORT_SYMBOL(splice_direct_to_actor);
 

Signature · 2 lines

-- 
Jens Axboe

Quoted 7 lines · Jens Axboe

Quoted 3 lines · J. Bruce Fields

Hm. It's still missing a case. I've confirmed that the following fixes the problem. (Or maybe it would be better to have them "goto" a common out with the file_accessed() check?)

Indeed it is, insert standard disclaimer here on the evil of multiple returns. So can we agree that this then fixes both cases?

Yep, thanks! And I ran one more test just to make sure. Looks fine.

fs/splice.c +3 -1

index 0a0b79b..504a096 100644
@@ -1052,8 +1052,10 @@ out_release:
 	/*
 	 * If we transferred some data, return the number of bytes:
 	 */
-	if (bytes > 0)
+	if (bytes > 0) {
+		file_accessed(in);
 		return bytes;
+	}

=20
return ret;

Quoted 14 lines · Jens Axboe

fs/splice.c +3 -1

index 0a0b79b..504a096 100644
@@ -1052,8 +1052,10 @@ out_release:
 	/*
 	 * If we transferred some data, return the number of bytes:
 	 */
-	if (bytes > 0)
+	if (bytes > 0) {
+		file_accessed(in);
 		return bytes;
+	}
 

fs/splice.c out_release: · line 1060

Quoted 1 line

fs/splice.c +0 -0

 	return ret;

Does the (bytes > 0) test mean that read(2) on an empty file will not update the atime ? Not a big deal for me personally, but that would be inconsistent with local file system behaviour.

Quoted 9 lines · Andre Majorel

On 2008-01-29 19:30 +0100, Jens Axboe wrote:
=20

fs/splice.c

Quoted 3 lines

fs/splice.c +0 -1

index 0a0b79b..504a096 100644
--- a/fs/splice.c

=20
Does the (bytes > 0) test mean that read(2) on an empty file will not update the atime ? Not a big deal for me personally, but that would be inconsistent with local file system behaviour.

=20
Good point, I'll commit a fixup for that patch.