RE: doublecheck

> Folks,
>
> I'm sorry for falling behind on email. I should have kept up with
> these doublecheck changes.
>
> I really don't like the code that got just got added.
>
> when I originally wrote the doublecheck feature, it was to be used
> for offline debugging, never on a live production cache. Thats
> why -S option does nothing except abort() if it finds an anomoly.
> It was an undocumented "feature" that I had used a couple of times.
> Probably it should have been removed.
>
> The code that got committed makes my caches really really slow
> during a dirty rebuild.

Possible.
The way I use it:
- change the config so that it points to a new cache-dir
- reconfigure
- copy the config, change it so that it listens to a bogus
  port on loopback
- fire up the server with the check-only configuration, -S
- wait for it to finish, then shutdown it.
- return configuration to the original one, then reconfigure.

To do so I even parametrized my config through cpp :-)
(well, actually I also did that so that I can keep the configs of
N caches aligned)

> It is totallly unacceptable to call stat() for every file during
> rebuild, no matter if clean or dirty. The rebuild process needs
> to be made faster, not slower!

That's why I'd have liked it to be made asynchronous.
Rationale: to do a check:
- "unmount" one of the storedirs
- fork a process that starts a slow check
- when it's done, remount

If you have only one dir, tough luck, and you go with
the current solution.

> The swapin metadata MD5 and URL checks make sure that we don't swap
> in bogus data. I see these stat() calls as superfluous.
>
> I think what you want to do belongs more with the "validation"
> procedure. Better to start a background task that calls stat at
> a low rate if necessary, after the swap.state files have been fully
> read.

What happens when there's a swapin MD5 mismatch? I get a lot of those
after a dirty shutdown...

-- 
	/kinkie, too lazy to go read the code.