Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 29 Jun 2006 00:50:23 +1000 (EST)
From:      Bruce Evans <bde@zeta.org.au>
To:        Ivan Voras <ivoras@fer.hr>
Cc:        freebsd-fs@FreeBSD.org
Subject:   Re: Is the fsync() fake on FreeBSD6.1?
Message-ID:  <20060629002637.L75228@delplex.bde.org>
In-Reply-To: <20060628230439.M75051@delplex.bde.org>
References:  <a0cd7c070606270032h3a42de6ahf21cd11abedb6400@mail.gmail.com> <44A1B958.4030204@fer.hr> <20060628230439.M75051@delplex.bde.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 29 Jun 2006, I wrote:

> ...
> fsync()ing /dev/null and /dev/ttyv1 is apparently slow because I (or
> someone at my request) prematurely removed the hack for not syncing
> file times for device files.   IN_LAZYMOD was supposed to make the
> hack unnecessary, but I never got around to making IN_LAZYMOD apply
> more generally.  In -current, it only applies to device files that are

However, it always applied all timestamps in device files in the non
soft updates case, so removing the hack was correct and there is a bug
that makes fsync() not honor IN_LAZYMOD.  I tested the effectiveness
of IN_LAZYMOD mainly for sync().

The bug is probably in my code.  From my version of ffs_fsync():

%1 	if (ap->a_waitfor == MNT_WAIT &&
%2 	    (vp->v_mount->mnt_flag & MNT_RDONLY) == 0)
%3 		VTOI(vp)->i_flag |= IN_MODIFIED;
%4 	VI_UNLOCK(vp);
%5 	splx(s);
%6 	return (UFS_UPDATE(vp, wait));

I added lines 1-3.  This forces an inode write.

Line 6 is dubious too.  If there was a delayed write pending for the
inode (which is normal after a write(2) to the file), then previous
code in ffs_fsync() should have written the inode.  Line 6 then risks
dirtying the inode and writing it again.  I think this happens in the
following case: any activity on the file that causes a delayed write
for the inode (e.g., a write(2)), followed by activity that just marks
a timestamp for update.  Then previous code in ffs_fsync() should write
the inode, but ffs_update() will find that a timestamp is not up to
date, set the timestamp, and write the inode again.  The second write
is often not very slow since it is a delayed write, but here we have
wait != 0, so a a sync write is forced modulo bugs in the async mode
case.  I think the UFS_UPDATE() in the above should be at the beginning
of ffs_fsync() instead of at the end, or in both places (an async one
at the beginning to update the timestamps in the in-core inode so that
the second sync one at the end is usually null).

> not in devfs and on ffs without soft updates, but there are no such
> files so it never applies.  In my kernel, it applies to all files but
> still only for atimes and not for soft updates.

In my kernel, it applies for all timestamps on device files and to atimes
on all files, except in the soft updates case.

Bruce



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060629002637.L75228>