(Illustration by Gaich Muramatsu)
On Mon, Jan 22, 2001 at 07:36:21PM +0100, Steffen Neumann wrote: > Hi, > > We are setting up the production server now, > and I am planning partition sizes. > > Going through the various docs I found > several figure for RVM Log and Data sizes... > > Data size seems to be consistently 4% of coda storage size. > > But in the section "The Log Partition" in the document > www.coda.cs.cmu.edu/doc/html/manual/x1657.html#RVMLOGPARTITION > LOG is the same 90M size than Data. Is that a typo ? > > We'd like to use the following Partitions, > with a single server serving some 8 Laptops: > > Partition StoragePurpose Mounted Size Whether fscked > > sda6 RVM Log Not 30M No > hda5 RVM Data Not 400M No > > hda6 Coda FS Data0 /vicepa 4G Yes > hda7 Coda FS Data1 /vicepb 4G Yes > > So, is the Log area way too small ??? No, log needs to be just big enough to store the largest transaction, which is normally during reintegration. The larger the log, the fewer truncations are needed, i.e. applying logged modifications to the data segment. However, every truncation processes more data and will therefore take longer. This could be offset by the fact that better optimizations can be performed, such as merging of adjacent modifications and cancellation of earlier modifications with later ones. However, these optimizations are currently disabled in the servers to improve stability. A server with between 2 and 4 MB of RVM log shouldn't really have any problems. About every 4096 operations, the servers dump out a lot of statistics to the SrvLog. Search for "Printing RVM statistics". The interesting numbers are probably: Average truncation time (sec): 1 Log used: 1% 33% Total Truncation Timings (sec): <=1 <=10 <=100 <=500 > 500 2814 518 2 1 0 This is from a server with 10MB RVM log, it peaked at 33% log usage, i.e. just over 3MB. The longest truncations time was between 100 and 500 seconds. Basically everything longer than 10-15 seconds will potentially cause the server to be perceived as `down' by the clients, so this happened about 3 times because of log truncation, however these large truncations probably happened during server startup. > Does anything else look badly broken ? No, everything looks fine. JanReceived on 2001-01-22 14:33:33