From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: From: erik quanstrom Date: Mon, 9 Apr 2007 11:24:41 -0400 To: 9fans@cse.psu.edu Subject: Re: [9fans] bell-labs website and plan9 In-Reply-To: <9ab217670704090808x410679d6ga64838b3be76e55b@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Topicbox-Message-UUID: 4195420c-ead2-11e9-9d60-3106f5b1d025 On Mon Apr 9 11:08:49 EDT 2007, devon.odell@gmail.com wrote: > > what do you mean by this? > > ``I don't know'' and I don't really care either. Apparently he doesn't > like that it takes forever and that it has the habit of wiping things > out sometimes. That's my understanding of his explanation, anyway. > > I'd rather not go down this thread though because I don't really want > to talk about why this work isn't happening, but rather what can be > done to make it happen and actually getting it done. rather a worked-up response for a simple question. for the record, i think many people on this list are interested in fixing things. if this is a pet project of yours, why don't you work on fixing it? unfortunately, i don't have very much spare time right now. there are drivers to write. i have also noticed that replica/applylog has a problem. when i started experimenting with copying history from our old fileserver to the new one, i started using replica/updatedb and replica/applylog. updatedb worked very well, but applylog hung for me pretty consistantly. my thought was that applylog has a threading deadlock, but i didn't spent much time thinking about it. one thing that does help quite a bit is to use replica/compactdb on your local database. that is in /dist/replica/plan9.db. - erik