On Thu, Jan 22, 2015 at 02:27:42PM +0100, Ronald Klop
wrote:> Hello,
>
> Tested on 10.1-STABLE/amd64 and 11-CURRENT/arm.
>
> I spotted this because rrdtool didn't update mtime of the database
files
> so they were not backuped by my rsync scripts.
>
> I remembered and found these mails from November 2014 about mtime+mmap on
> ZFS.
>
https://lists.freebsd.org/pipermail/freebsd-stable/2014-November/081138.html
> which resulted in
>
https://lists.freebsd.org/pipermail/freebsd-stable/2014-December/081184.html
>
> My tests with the test program in the November mails result in:
> On 10.1-STABLE/ZFS its OK:
> $ 14:18:08 ronald at sjakie [~/test]
> ls -lT mdata; /tmp/a.out mdata; ls -lT mdata
> -rw------- 1 ronald staff 1024 Jan 22 14:18:08 2015 mdata
> -rw------- 1 ronald staff 1024 Jan 22 14:18:10 2015 mdata
>
> On 11/UFS its OK:
> $ 14:16:16 ronald at sheeva [~/test]
> ls -lT mdata; /tmp/a.out mdata; ls -lT mdata
> -rw------- 1 ronald staff 1024 Jan 22 14:16:16 2015 mdata
> -rw------- 1 ronald staff 1024 Jan 22 14:16:21 2015 mdata
>
> On 11/tmpfs it fails: (same on 10.1-STABLE/tmpfs)
> $ 14:15:44 ronald at sheeva [/tmp]
> ls -lT mdata; /tmp/a.out mdata; ls -lT mdata
> -rw------- 1 ronald wheel 1024 Jan 22 14:15:37 2015 mdata
> -rw------- 1 ronald wheel 1024 Jan 22 14:15:37 2015 mdata
>
> Should a similar patch as ZFS got be applied to tmpfs?
In what way patch for tmpfs would be similar to zfs one ?
Tmpfs architecturally makes it impossible or relatively hard to detect
modifications to the pages of the tmpfs file through mmaping. The reason
is that tmpfs files for VM look exactly like anonymous shared mappings.
This is progress comparing with the initial tmpfs port, where mmaped
data was double-copied.
The detection of modifications could be done, e.g. by utilizing syncer
to make a pass over all active vnodes and converting OBJ_MIGHTBEDIRTY
flag for the backing vm object into mtime update. Of course, VM must be
modified to also set the flag or its analog (OBJT_MIGHTBEDIRTYTMPFS ?)
for tmpfs vm objects. This is what I mean above as 'relatively hard'.
I will review (and commit) the patch along these lines.