From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <399701de46c1549a561ad1d764126792@granite.cias.osakafu-u.ac.jp>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] disk/^(mbr format fdisk prep)
From: Kenji Okamoto <okamoto@granite.cias.osakafu-u.ac.jp>
Date: Fri, 14 May 2004 10:03:38 +0900
In-Reply-To: <3bbf5f5085c5b529f90850833a4371a5@davidashen.net>
MIME-Version: 1.0
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Topicbox-Message-UUID: 7a767686-eacd-11e9-9e20-41e7f4b1d025

> With fossil, it has been much faster.

Why I didn't employ fossil this time, because I needed fully robust file
system for this AUTH server.   I needed this standalone AUTH server,
because I don't want to depend its function to any one of file servers
themselves.   I'm going to live with double file server, Ken's and Fossil
+Venti soon, where we have to keep all our system non-stop.   So the
robust and standalone AUTH server was necessary.

For the speed of kfs on CF, I agree with thatit's terriblly slow to write
to kfs on CF, which made me much surprise.   I had to play with web
browser wen I was installing things to that CF kfs.   However, we need
mainly just reading from this CF kfs for AUTH server, then, speed issue
is not serious to me.

Kenji