From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: Date: Thu, 27 Sep 2007 23:16:46 -0400 From: "Russ Cox" To: "Fans of the OS Plan 9 from Bell Labs" <9fans@cse.psu.edu> Subject: Re: [9fans] More venti sync woes. In-Reply-To: <509071940709271549l57a778e5k9d0f70e3d3a670be@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <509071940709261232t1046ecv2ce6800d549c180c@mail.gmail.com> <509071940709271549l57a778e5k9d0f70e3d3a670be@mail.gmail.com> Topicbox-Message-UUID: c67465b6-ead2-11e9-9d60-3106f5b1d025 dma is worth around 10x, certainly less than 50. i agree that your venti server is taking a very long time to come back. i reboot mine all the time and don't have this problem. i am at a loss for what could be taking it so long. it's probably not going to hurt any to stop it. it could take forever -- maybe it's looping! when you manage to boot in other means, it would be nice to see what ps -a|grep venti says. venti sets its proc args that show up in ps -a to tell you what each proc does. the new venti is very careful both about the consistency of what is stored on disk and about recovering quickly after a disk failure (there's not a lot to do -- just pick up the unindexed arena entries from the arena tocs and toss them back into the index write buffer where they were when you restarted the system). what you're describing could happen if you were running a new venti (which buffers index updates quite aggressively) and then on reboot managed to start an old venti (which would then process the unindexed new blocks one at a time instead of buffering the updates, with about 3 seeks per block). without more information i'm afraid i have no good answers. russ