From owner-freebsd-stable@FreeBSD.ORG Fri Jan 23 08:46:52 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 78D0F52C for ; Fri, 23 Jan 2015 08:46:52 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E0B6615F for ; Fri, 23 Jan 2015 08:46:51 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id t0N8kjK4094234 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 23 Jan 2015 10:46:45 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua t0N8kjK4094234 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id t0N8kju6094233; Fri, 23 Jan 2015 10:46:45 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 23 Jan 2015 10:46:45 +0200 From: Konstantin Belousov To: Ronald Klop Subject: Re: mmap on tmpfs not updating mtime Message-ID: <20150123084645.GE42409@kib.kiev.ua> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2015 08:46:52 -0000 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.