Date: Fri, 23 Jan 2015 10:46:45 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: Ronald Klop <ronald-lists@klop.ws> Cc: freebsd-stable@freebsd.org Subject: Re: mmap on tmpfs not updating mtime Message-ID: <20150123084645.GE42409@kib.kiev.ua> In-Reply-To: <op.xsu80gb9kndu52@ronaldradial.radialsg.local> References: <op.xsu80gb9kndu52@ronaldradial.radialsg.local>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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@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@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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150123084645.GE42409>