On Mon, 01 Dec 2014 10:10:11 +0200
Andriy Gapon <avg at FreeBSD.org> 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