On Fri, Nov 05, 2004 at 09:39:53AM -0500, David Krinsky wrote:
> Yes, that does sound likely.
> 
> > It has also been seen by someone else on completely different harware, which
> > rules out a driver or machdep issue. He also had a file system full condition
> > just before the problem. On my server I didn't have this, but I have quotas,
> > and the effect it probably the same at the filesystem level when a user is
> > overquota. Both of us have NFS in the game, but I guess in your case
> > / and /usr are not NFS exported ?
> 
> Correct.  I have neither quotas nor NFS active at all on this system.

OK, so it looks like the problem isn't NFS-related either.
This points to an issue in the VM system. One senario could be this one:
when a filesystem full (or overquota) error occurs, the page mapped to
the file (file1) is freed and can be recycled for use by another open file
(file2). But something in the file1 management keeps a reference to this page,
and a subsequent write to file1 will change data in this page and mark it
dirty. So even if the page now points to a read-only file, as it has been
marked dirty the corrupted data are written back to disk to file2.

Now, I don't know the UBC internals in details, so I don't know where to start
looking ...

-- 
Manuel Bouyer <bouyer@antioche.eu.org>
     NetBSD: 26 ans d'experience feront toujours la difference
--