Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 27 Apr 1998 22:25:28 +1000
From:      Bruce Evans <bde@zeta.org.au>
To:        dima@tejblum.dnttm.rssi.ru, freebsd-fs@FreeBSD.ORG
Subject:   Re: VFS_SYNC(MNT_LAZY)
Message-ID:  <199804271225.WAA01699@godzilla.zeta.org.au>

next in thread | raw e-mail | index | archive | help
>This is called every 30 seconds by the syncer daemon for every 
>filesystem mounted read-write.
>
>Is there any good reason why every filesystem walk through list of all 
>vnodes, lock every vnode, check for waitfor == MNT_LAZY, and in this 
>case unlock and skip the vnode? 

Well, in ffs_sync(), the loop checks for pending updates.  I can't see
anywhere else where this is done.  OTOH, after finding a pending update,
it is probably a pessimization to do a full VOP_FSYNC() instead of just
an !MNT_NOWAIT update whose delayed write would eventually be handled
by the syncer daemon.  This assumes that the (waitfor == MNT_LAZY)
check is correct and we're not depending on the vnode getting fsynced
as a side effect of finding a pending update.

msdosfs_sync() and ext2fs_sync() seem to be just broken.  msdosfs_sync()
has the (waitfor == MNT_LAZY) check in a different place, so the check
can be moved outside of the loop.  I can't see how pending updates can
work right.  ext2fs_sync() is missing the check, so it does even more
premature VOP_FSYNC()s than ffs_sync().

>I may replace this with goto around this loop, if nobody object.

I object :-).

>Then, ffs_sync does not "flush filesystem control information" with 
>MNT_LAZY. (That is, it doen't call VOP_FSYNC on the device). Should it 
>be same way in other filesystems?

I think the only "filesystem control information" is bitmap blocks, and
the syncer daemon handles the write, somewhat more delayed than before.
Superblocks are still written using async writes in the !MNT_NOWAIT
case.  I think delaying all these writes as long as the syncer daemon
wants to is correct.  Bitmap blocks are written using delayed writes
even in the MNT_SYNCHRONOUS 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?199804271225.WAA01699>