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.
Jan
