> It seems to only happen once per boot, but not necessarily when fossil > starts responding--I've seen it a couple hours after booting, which > the filesystem tends to go away at night.
the failure is somewhere in blockWrite. since blockWrite calls diskWrite and diskWrite just queues up i/o to send to the disk, it's not possible to get i/o errors directly from blockWrite. there are two case that do return errors. one is if the block can't be locked. a runaway periodic function would make that more likely, since we don't wait for the lock. but it seems more likely in this case that some of fossil's data is corrupted since this started after the double-failure. see http://9fans.net/archive/2009/03/487 the other case is a funny dependency. there's a fprint there that's commented out. - erik
