From owner-freebsd-fs@FreeBSD.ORG Wed Jun 28 14:50:28 2006 Return-Path: X-Original-To: freebsd-fs@FreeBSD.org Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8274B16A417 for ; Wed, 28 Jun 2006 14:50:28 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailout2.pacific.net.au (mailout2.pacific.net.au [61.8.0.115]) by mx1.FreeBSD.org (Postfix) with ESMTP id CE38E43D70 for ; Wed, 28 Jun 2006 14:50:27 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy2.pacific.net.au (mailproxy2.pacific.net.au [61.8.2.163]) by mailout2.pacific.net.au (Postfix) with ESMTP id A40D46E2DE; Thu, 29 Jun 2006 00:50:26 +1000 (EST) Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailproxy2.pacific.net.au (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k5SEoNUZ009114; Thu, 29 Jun 2006 00:50:24 +1000 Date: Thu, 29 Jun 2006 00:50:23 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Ivan Voras In-Reply-To: <20060628230439.M75051@delplex.bde.org> Message-ID: <20060629002637.L75228@delplex.bde.org> References: <44A1B958.4030204@fer.hr> <20060628230439.M75051@delplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-fs@FreeBSD.org Subject: Re: Is the fsync() fake on FreeBSD6.1? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2006 14:50:28 -0000 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