On Aug 10, 2010, at 6:27 AM, Jan Lehnardt wrote: > This looks like we are recovering nodes that don't need recovering because on > a healthy db produced with delayed_commits=true we should not have any > orphans at all, so the lost and found db should be empty.
Yes, that would be ideal. I think the issue is that "prune_nodes" ends up returning all btree roots except the latest one. It doesn't actually grab all the headers and remove root nodes they point to, it only does this for the latest header. As a result, I think rnewson's results make sense. On Aug 10, 2010, at 4:55 AM, Robert Newson wrote: > In ran the db_repair code on a healthy database produced with > delayed_commits=true. > > The source db had 3218 docs. db_repair recovered 3120 and then returned with > ok. > > I'm redoing that test, but this indicates we're not finding all roots. On a healthy DB it should have found zero docs. It probably found all docs except those which are accessible only from the latest header. On Aug 10, 2010, at 4:09 AM, Mikeal Rogers wrote: > I think I found a bug in the current lost+found repair. > > I've been running it against the testwritesdb and it's in a state that is > never finishing. I'll bet it's working ok. prune_nodes() returns 26000+ roots for that DB, so we need to do 26000+ replications, each of which finds a large number of documents. The solution is to prune more nodes. Adam
