Date: Mon, 26 Nov 2001 11:03:41 +0000 From: Ian Dowse <iedowse@maths.tcd.ie> To: Alfred Perlstein <bright@mu.org> Cc: Sean Chittenden <sean@chittenden.org>, Kris Kennaway <kris@obsecurity.org>, jlemon@freebsd.org, cvs-committers@freebsd.org, cvs-all@freebsd.org Subject: Re: cvs commit: src/usr.bin/tail forward.c Message-ID: <200111261103.aa12722@salmon.maths.tcd.ie> In-Reply-To: Your message of "Mon, 26 Nov 2001 03:22:26 CST." <20011126032226.F13393@elvis.mu.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <20011126032226.F13393@elvis.mu.org>, Alfred Perlstein writes: >This is really to affdress the issue of FSs that don't support EVFILT >VNODE (or whatever it is) properly. No, as Kris mentioned, this is not the issue. The -F option worked fine on filesystems that don't support kqueue because tail always polls in that case. The problem that this commit worked around was a feature of tail's "-F" option that was lost when tail was kq-ified: that is the ability to always notice when the command-line path starts referring to a different file. In the -F case, tail sets up two kevents on the specified file: EVFILT_READ EVFILT_VNODE (fflags NOTE_DELETE, NOTE_RENAME) This causes tail to be notified when file size changes, or whenever the file is renamed or deleted. The problem is that there are other changes that are not caught by this filter but which are noticed when polling. Consider the case of tail -F /var/log/today/messages mv /var/log/today /var/log/20011126 mkdir /var/log/today touch var/log/today/messages The vnode being monitored sees no changes, so no kevent is generated. The above example is a simple case; more generally there can be any number of directories and symbolic links in the path, and some path components may not be on filesystems that support kqueue. The case where all path components are on a kqueue-supported filesystem could be dealt with using no polling, but it would involve a procedure that is something like: - Split up the specified path into its components, and set up a kevent for each one, resorting to polling if any fail. - Expand any components that are symlinks, and set up kevents for each one, repeating as necessary. - Whenever we get a kevent for one of the intermediate path components, re-scan all path components after that one, including re-expanding symlinks. Then re-stat the path to see if the referenced file has changed (you can't even short-cut the rescan by stat'ing first, because the path could be now taking a different route to the same file, causing some further changes to be missed). And even then, there are races possible, so some changes could be missed. Ian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi? <200111261103.aa12722>