Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 13 Oct 2002 17:24:35 +1000 (EST)
From:      Bruce Evans <bde@zeta.org.au>
To:        Peter Godman <pete@isilon.com>
Cc:        freebsd-fs@FreeBSD.ORG
Subject:   Re: ufs_update and waitfor flag
Message-ID:  <20021013163315.F21287-100000@gamplex.bde.org>
In-Reply-To: <Pine.BSF.4.21.0210121624030.66567-100000@isilon.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 12 Oct 2002, Peter Godman wrote:

> An application running on my system is doing basically:
>
> 	fd = open(file)
> 	read(fd, ...)
> 	fsync(fd)
> 	close(fd)
>
> My root filesystem is mounted sync,noatime, but this sequence of
> operations still results in a bwrite during fsync in ufs_update.  This
> seems to be the result of the following code in ufs_update:
>
> int
> ffs_update(vp, waitfor)
> 	struct vnode *vp;
> 	int waitfor;
> {
> 	struct fs *fs;
> 	struct buf *bp;
> 	struct inode *ip;
> 	int error;
>
> 	ufs_itimes(vp);
> 	ip = VTOI(vp);
> 	                                    /* vvvvvvvvvvvv  ?? */
> 	if ((ip->i_flag & IN_MODIFIED) == 0 && waitfor == 0)
> 		return (0);
> 	ip->i_flag &= ~(IN_LAZYMOD | IN_MODIFIED);
>
> 	...
>
> The relevant part here is the "waitfor == 0" in the bailout check.  Though
> the flags on the inode do not indicate that the inode is modified, the
> fact that we wish to wait for the operation to complete results a write
> happening here that otherwise wouldn't have.  Do other people read this
> code the same way?  Is this desired or expected behaviour?  What would
> happen if I commented out the check for waitfor == 0 at this
> point?  Anyone know why this check is there?  Most likely I will modify
> the application in question, but would like to know whether this code
> should change too.

The waitfor test was added in th first round of soft updates changes for
reasons that I never completely understood.  I vaguely remember that it
is to get the DOINGSOFTDEP() case a little later in ffs_update() reached.
I never liked this.  It certainly seems to be wrong for fsync(2).
ffs_fsync() is caled with waitfor set in that case, and we eventually
write the inode even when it was perfectly clean.

I'm fairly sure that you can remove the waitfor test in the
!DOINGSOFTDEP() case.

Bruce


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-fs" in the body of the message




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