> From: Jan Harkes [mailto:jaharkes_at_cs.cmu.edu]
> On Thu, May 17, 2001 at 11:05:51AM +1200, Steve Wray wrote:
> > > From: Shafeeq Sinnamohideen [mailto:shafeeq_at_cs.cmu.edu]
> > > On Wed, 16 May 2001, Steve Wray wrote:
> > >
> > > > > It doesn't matter what kind of FS is used on the server. Only
> > > the client
> > [snip]
> > > >
> > > > I'm not sure how to interpret your comment about the client...?
> > >
> > > The client venus cache partition must be on an ext2, reiser, or ramfs
> > > partition for it to work. This is because when the Coda
> kernel module gets
> > > a request, it must be able, in the kernel, to forward it to the file
> > > system that contains the container file so it can do the operation.
> >
> > Which is the container? /vicepa?
> > Is that the cache partition on the client?
> > I'm still groping around the terminology here...
>
> No, /vicepa is on the server. The server doesn't do any tricky stuff, so
> it doesn't matter what type of filesystem is used.
>
> On the client, the file data is stored in 'container files', which are
> located under /usr/coda/venus.cache/. When an application opens a file
> in /coda, the cachemanager opens the associated container file and
> passes the filedescriptor (before 2.4.4 it was device/inode numbers)
> back.

ohhhhhhhh I get you now. I think this could be made clearer in the howto?
I'd be tempted to put this on its own partition.
What are the guidelines for how much space should be allocated?



> > On the toy client I was working with, all partitions
> > were LVM/XFS except for those holding rvmlog and rvmdata,
> > these were seperate logical volumes and were unformatted.
>
> LVM (like RAID) shouldn't have any influence because it operates on a
> much lower layer, the block layer. If you didn't see any strange
> behaviour, especially when writing to files in /coda, XFS must be using
> the generic read/write calls.

Well... I'd call the incredible slowness strange behavior, but that
was mostly strange from the perspective of the server, not the
client.
Tho the server was running venus...


[lots of snips]
> > > Generally, placing the log file an a separate physical disk will help,
> > > since only the log needs to be appended to synchronously, while the
data
> > > file and /vicepa can be written lazily.
> >
> > It can be hard to arrange that on LVM...
> > :)
> > it kinda makes the disks transparent...
>
> We really should do logging differently, for debugging it is useful to
> log unbuffered (or use fsync after every fprintf). However, for
> production use and performance reasons it would be better to allow both
> libc and the OS to buffer writes. Performance really hasn't been a
> concern yet, and there are probably many places where we can do a lot
> better with simple changes, like reducing the amount of unnecesary
> information in the logs and removing fsync's after fprintf's.

Maybe some configure or compile flags to optimise
rather than debug?
:)