Date: 17 Oct 2001 15:12:35 +0200 From: Dag-Erling Smorgrav <des@ofug.org> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: John Baldwin <jhb@FreeBSD.ORG>, Bruce Evans <bde@FreeBSD.ORG>, fs@FreeBSD.ORG Subject: Re: Some questions regarding vfs / ffs Message-ID: <xzplmiah0l8.fsf@flood.ping.uio.no> In-Reply-To: <xzphesyu90n.fsf@flood.ping.uio.no> References: <XFMail.011016191649.jhb@FreeBSD.org> <xzpk7xvvwbw.fsf@flood.ping.uio.no> <200110170229.f9H2Tph84237@apollo.backplane.com> <xzpg08jvsg6.fsf@flood.ping.uio.no> <xzphesyu90n.fsf@flood.ping.uio.no>
next in thread | previous in thread | raw e-mail | index | archive | help
Dag-Erling Smorgrav <des@ofug.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. DES -- Dag-Erling Smorgrav - des@ofug.org 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?xzplmiah0l8.fsf>