Dag-Erling Smorgrav <firstname.lastname@example.org> writes:
> Actually, there's nothing screwy about sched_sync(), except that I
> overlooked the fact that it calls sync_fsync() (through VOP_FSYNC())
> which calls ffs_sync(). Judging from collected stats, I'm wondering
> if there's really any point in calling ffs_sync() (indirectly) from
> sched_sync(), as it seems to rarely actually *do* much except screw up
> my interrupt latency. I guess it's useful as a safety net, but I
> don't really see how a vnode can be dirty and not on the sync list?
This apparently *does* happen, but rarely enough that it might be a
race condition between the syncer and the code I added to cound vnodes
that ffs_sync() considered dirty but that weren't on the worklist.
I thought it might happen when the file system was mounted async, but
apparently it doesn't; the only case in which I'm not entirely sure
that a dirty vnode is put on the worklist is when it's dirtied by a
pure metadata update, but empirical tests show that doing tons of
metadata updates (touch(1)ing hundreds of thousands of files) does not
significantly increase the number of dirty vnodes that are not on the
worklist, even on an async file system.
Dag-Erling Smorgrav - email@example.com
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-fs" in the body of the message