On Sun, Mar 14, 2004 at 07:18:40PM -0800, Steve Simitzis wrote:
> On 03/14/04, Jan Harkes <jaharkes_at_cs.cmu.edu> wrote: 
> > This wouldn't happen all too often, a server restart should fix it. I'll
> > have a look to see how I can avoid the race, either temporarily blocking
> > the growth of the original volume, or by restarting the clone when the
> > numbers don't match up.
> 
> the problem i had was that restarting the server took about an hour,
> which the server spent destroying a damaged backup volume during the
> initial salvage run. :/

Yeah, when cloning the backup volume fails, it is destroyed. But because
of the copy-on-write between original and backup volumes it should only
have to destroy some of the metadata and not really touch any of the
container files.

I guess that updating the ftreedb file in /vicepa is probably one of the
bigger slowdowns here, it explicitly fsyncs every time the linkcount is
decremented but without profiling I can't really tell. An hour
definitely sounds quite bad performance wise.

Jan