Date: Wed, 27 Oct 2004 02:15:27 -0700 (PDT) From: Don Lewis <truckman@FreeBSD.org> To: phk@phk.freebsd.dk Cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/kern vfs_subr.c src/sys/sys buf.h bufobj.h vnode.h Message-ID: <200410270915.i9R9FRIa019936@gw.catspoiler.org> In-Reply-To: <61934.1098866287@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
On 27 Oct, Poul-Henning Kamp wrote: > In message <200410270824.i9R8OqGc019841@gw.catspoiler.org>, Don Lewis writes: >>On 27 Oct, Poul-Henning Kamp wrote: >>> phk 2004-10-27 08:05:03 UTC >>> >>> FreeBSD src repository >>> >>> Modified files: >>> sys/kern vfs_subr.c >>> sys/sys buf.h bufobj.h vnode.h >>> Log: >>> Move the syncer linkage from vnode to bufobj. >>> >>> This is not quite a perfect separation: the syncer still think it knows >>> that everything is a vnode. >> >>This change strikes me as wrong. The syncer has to handle things like >>inode timestamps (utimes(2)) and fifos, which I wouldn't expect to have >>bufobjs. > > The syncers job is to push dirty buffers onto disk. In the process it > will need to call back into whoever owns the buffer so they can do their > private housekeeping as necessary. > > So the syncer doesn't deal with timestamps, the filesystems do. One of the things that is on my list of things to do is to handle timestamp updates by putting them on the syncer worklist. I stumbled across a bug a while back that causes files being written to be synced twice as often as they should. The file gets synced once when the syncer comes across it it on the worklist, and it gets synced again when the syncer encounters the file system syncer vnode, which results in a call to ffs_sync(), which syncs all the vnodes that have pending inode timestamp changes. This second sync can result in a large burst of activity if there are a lot of pending timestamp changes. This is quite noticable when unpacking a large tarball or doing something similar that writes to a lot of files. There are large bursts of disk activity every 30 seconds and the machine gets noticeably sluggish. If you monitor the length of the syncer worklist, it will vary in a sawtooth manner. I discussed this privately with mckusick a while back and he told me that the original intent was to not walk the vnode list in ffs_sync() in the MNT_LAZY case. The problem was that timestamp updates could end up being deferred indefinitely if no buffers were dirtied. Skipping the vnode list traversal in ffs_sync() in the MNT_LAZY case would also be a nice optimization just in terms of CPU time because this list can be quite long. It also makes sense to sync the timestamps stored in the inode and the file data blocks at the same time because the block pointers stored in the inode may need to be updated.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200410270915.i9R9FRIa019936>