From owner-freebsd-stable@FreeBSD.ORG Tue Dec 2 12:16:09 2014 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 6C60A285 for ; Tue, 2 Dec 2014 12:16:09 +0000 (UTC) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id BE334F99 for ; Tue, 2 Dec 2014 12:16:08 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id OAA16240; Tue, 02 Dec 2014 14:17:55 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1XvmN6-000O33-IZ; Tue, 02 Dec 2014 14:16:00 +0200 Message-ID: <547DAD48.2010407@FreeBSD.org> Date: Tue, 02 Dec 2014 14:15:04 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Paul Koch Subject: Re: 10.1 mmap on zfs not updating mtime References: <20141125142302.1199041c@akips.com> <547C2263.3000001@FreeBSD.org> <20141202112707.5ee84c5a@akips.com> In-Reply-To: <20141202112707.5ee84c5a@akips.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit 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 12:16:09 -0000 On 02/12/2014 03:27, Paul Koch wrote: > 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. Thank you for reporting the problem and testing the patch! > 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. -- Andriy Gapon