(Illustration by Gaich Muramatsu)
(Illustration by Gaich Muramatsu)
On Thu, Dec 13, 2001 at 02:38:38PM -0800, David J. M. Karlsen wrote: > <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> > <html> > <head> > <title></title> > </head> > <body> > Jan Harkes wrote:<br> Could you fix you mailer, I am not a webbrowser. > <pre wrap=""><!----><br>If the SCM dies the only thing that is hindered > is adding new<br>users/changing passwords and the creation of new > volumes.</pre> > </blockquote> > they can still authenticate as well? (eg. use clog?) Only if you specified multiple server as 'rootservers' or 'authservers' in /etc/coda/venus.conf. Venus and clog should just iterate through the list until they hit a server that is running an auth2 daemon. > Some things abount the README at the ftp site:<br> > first: it's for version 4.6.1 - should't it just be removed?<br> Probably, I obviously haven't looked at it since 4.6.1 was released. > also:<br> > it referres to a venus-setup script that does not exist.<br> It exists in the RedHat package and on the BSD's, for Debian I've moved all the functionality into debconf, so you can use 'dpkg-reconfigure coda-client' to do the same thing. I probably should add a silly wrapper-script called venus-setup to the Debian package that just calls dpkg-reconfigure. > it tells me to run createvol_rep after running vice-setup.<br> > Is this wrong? Beacuse when I first went into /coda/<myvol> the Ehhh, my guess is that venus failed to start up and you created 'myvol' on the local disk because /coda wasn't mounted. > existed. I ran createvol_rep - and now it's not there anymore... Doesn't > the vice-setup do the createvol_rep as well?<br> No, it takes some time to start the server and createvol_rep will fail as long as it isn't up and running. So you have to wait for 'File Server started' to show up in /vice/srv/SrvLog, which makes it pretty hard to write a reliable script that can do the same thing. > second: the README says that the LOG has to be large - isn't this wrong? > The RVM needs to be large - the LOG doesn't?<br> The log needs to be big enough to handle the biggest transaction that could occur. Normally 2MB seems to be ok. > Else:<br> > codasrv uses and awfaul amount of mem - (eg. equal to the size of RVM).<br> > I thougth it just did this when using files for LOG/RVM (beacuse they are > mmap'ed) - but when I switched over to using partitions - it uses the same > amount anway - is there a way to awoid this - the testmachine has only got > 64 megs.<br> To guarantee that we don't mess with the on-disk RVM data during transactions. Initially the RVM data is copied to memory, all modification are on the in-memory copy and logged in the RVM log. Once in a while we truncate the log by applying the pending modifications to the on-disk RVM data. When a server starts it initially commits all logged operations to get the on-disk data back in sync and then reloads the data into memory. However, when you use files as a backing store for RVM, we can use a private mmap. The advantages are, although the process size looks huge, the system can simply drop and reload any unmodified pages from the RVM data file. Once when we dirty the page it is copied to anonymous memory and therefore has to be written to swap when there is memory pressure. As normally large parts of RVM are not being modified, we are a lot easier on the kernel's VM system when operating like this. > (Does this have anyting to do with the privatemap=0/1 in the > /etc/coda/server.conf?)<br> Yup, see explaination above. JanReceived on 2001-12-13 18:04:08