On Thu, Jun 18, 2009 at 9:45 AM, erik quanstrom <quans...@quanstro.net> wrote: > > > 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 >
Here's another message that may be of interest. I ran fshalt before rebooting (to test the periodicthread patch) and saw this: syncing.../srv/fscons...prompt: sourceRoot: fs->ehi = 5395, b->l = BtDir,3,Copied,e=5394,-1,tag=0x1 venti... halting.../srv/fscons...archive vac:a9d9b0b9fe0db783fe618f680804a18df532a67a I don't remember seeing that "sourceRoot: ..." stuff before; as soon as the system comes back up I guess I'll take a look at source. John -- "I've tried programming Ruby on Rails, following TechCrunch in my RSS reader, and drinking absinthe. It doesn't work. I'm going back to C, Hunter S. Thompson, and cheap whiskey." -- Ted Dziuba
