Re: Is the fsync() fake on FreeBSD6.1?
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[/color]
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;
%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.[/color]
In my kernel, it applies for all timestamps on device files and to atimes
on all files, except in the soft updates case.
[email]firstname.lastname@example.org[/email] mailing list
To unsubscribe, send any mail to "email@example.com"