From owner-freebsd-stable@FreeBSD.ORG Tue Dec 2 01:27:58 2014 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CDB08B05; Tue, 2 Dec 2014 01:27:58 +0000 (UTC) Received: from mail.akips.com (mail.akips.com [65.19.130.19]) by mx1.freebsd.org (Postfix) with ESMTP id BA9BD814; Tue, 2 Dec 2014 01:27:58 +0000 (UTC) Received: from akips.com (CPE-120-146-191-2.static.qld.bigpond.net.au [120.146.191.2]) by mail.akips.com (Postfix) with ESMTPSA id E4D0728441; Tue, 2 Dec 2014 11:27:50 +1000 (EST) Date: Tue, 2 Dec 2014 11:27:07 +1000 From: Paul Koch To: Andriy Gapon Subject: Re: 10.1 mmap on zfs not updating mtime Message-ID: <20141202112707.5ee84c5a@akips.com> In-Reply-To: <547C2263.3000001@FreeBSD.org> References: <20141125142302.1199041c@akips.com> <547C2263.3000001@FreeBSD.org> Organization: AKIPS X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.22; amd64-portbld-freebsd10.1) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.0 required=5.0 tests=UNPARSEABLE_RELAY, URIBL_BLOCKED autolearn=disabled version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on host1.akips.com 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: Tue, 02 Dec 2014 01:27:58 -0000 On Mon, 01 Dec 2014 10:10:11 +0200 Andriy Gapon wrote: > On 25/11/2014 06:23, Paul Koch wrote: > > > > Hi, > > > > we have observed some odd behaviour with the mtime of a mmap'ed file > > when it has been updated on a zfs pool. The mtime does not appear to > > be updated. Seems to work ok on UFS. > > Could you please test the following simple patch? > Index: sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c > =================================================================== > --- sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c (revision 275036) > +++ sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c (working copy) > @@ -5969,6 +5969,7 @@ top: > &zp->z_pflags, 8); > zfs_tstamp_update_setup(zp, CONTENT_MODIFIED, mtime, ctime, > B_TRUE); > + (void)sa_bulk_update(zp->z_sa_hdl, bulk, count, tx); > zfs_log_write(zfsvfs->z_log, tx, TX_WRITE, zp, off, len, 0); > > zfs_vmobject_wlock(object); > > > Test program below... > > > > On 10.0, the following works ok: > > > > dd bs=1k if=/dev/zero of=mdata count=1 > > ls -lT mdata; /tmp/mmap-mtime mdata; ls -lT mdata > > > > but on 10.1 the mtime stays at its creation time. > [snip] > Applied the same change to 10.1-RELEASE and it fixed the problem. Don't know how this affects other applications running on 10.1, but we've applied a workaround for ours by calling futimes() after we do a fsync() or between munmap()/close() on a mmap'ed file. Paul. -- Paul Koch | Founder, CEO AKIPS Network Monitor http://www.akips.com Brisbane, Australia