sendfile syscall returns cached content => Fixed in SVN / 6.0.6

[MaximKulkin]

When using shared folder and copying file with sendfile syscall (either by just creating another file or sending content over network socket), the receiving end always gets the same content (the content that was in source file when sendfile called for the first time).

Repro steps:

1. Setup a linux box with shared folder (tested on Ubuntu 13.04).
2. Compile sendfile-copy.c (attached) inside VM:

   make sendfile-copy
   

3. Create a file "foo" in shared folder inside VM with contents "foo".
4. Use "sendfile-copy" app from step 2 to copy file "foo":

   ./sendfile-copy foo bar
   

5. Ensure that file "bar" contains string "foo":

   cat bar
   

6. Changed the contents of file "foo" to "bar". Ensure that file "foo" now contains "bar":

   cat foo
   

7. Copy file "foo" to "baz" with "sendfile-copy":

   ./sendfile-copy foo baz
   

8. Inspect the contents of file "baz":

   cat baz
   

You will see "foo" instead of "bar".

[CleanCut]

This prevents me from mounting volumes into docker containers in my development environment. They work initially, but when a file changes, everything messes up. The behavior I see is this:

If the file is changed but stays the same size we will call X:

• the container sees the original file

If the file is changed to be a shorter amount of bytes Y:

• the container sees the first Y bytes of the original file

If the file is changed to be a longer amount of bytes Z:

• the container sees the original file plus (Z - X) bytes of garbage.

[DHa]

+1

Related to #9069, which is less detailed but contains possible workaround.

[doozr]

+1

I created #14920 with detailed instructions on how to replicate in Docker. Also posted it to #9069.

[bronek]

Related: #819, #9069, #14920

[bird]

This should be addressed in 6.0.6, except for really really old kernels (< 2.5.30) where we cannot control what senfile does wrt caching. But even on those old kernels we will invalidate the cache if we notice st_mtime changes.