Hi Yves,

On Tue, Jul 01, 2008 at 10:34:19PM -0600, Yves Dorfsman wrote:
> Sorry, I meant server. I was assuming only one server (coming from NFS), 
> and will eventually move important files to it, and don't want to spend too 
> much time getting the server going in case of a hard crash. Reading your 

Actually, it would be a lot less of a problem than an NFS server crash.

> email and thinking more about it, I realised that I could use one of the 
> workstation as a secondary CODA server - neat.

Keep in mind that you want the (other) server
- be secured against unauthorized access
- be up all the time (short downtimes are mostly harmless but you possibly
  lose synchronization between servers, data may stay different until
  next access with both servers being up)

an that the server will be "shaky" from the point of view of the client
located on the same machine, see the mailing list/Wiki why.

> So, at least to satisfy my curiosity, assuming the server act also as a 
> client, that while a process is writing to that filesystem you were to pull 
> the power cord. The process was in the middle of writing, and the 

I don't buy it.

1. you do not want both a client and a server on the same machine,
unless you know the implications and _really_ know that you are fine with them

2. which process was in the middle of writing (presumably to disk)?
   An application? Venus? Codasrv?

I am aware of one very rare scenario when Venus (or was it codasrv?) refuses
to start when it detects inconsistency between its transactional internal
state storage (RVM) and the corresponding container files, which are not
transactional in the same sence. Venus does not know whether the file
[directory entry] has successfully been created on the disk before the crash
and bails out when it tries to create an already existing file.
This can be classified as a bug and possibly it is already fixed (?).
The workaround is to manually remove the (empty) container file.

> underlying FS is a logging FS, so the underlying FS is in a consistent 
> state, is that enough to guarantee that the CODA FS will be in a consistent 
> state ?

I can not give any guarantees :)

There is a chance you will sooner trigger some yet unfixed bug which
will corrupt a volume, than a crash by itself will lead to an inconsistency.
YMMV

> >>How often do you typically do the dump ?
> >I don't (if we think of the same "dump"?)
> 
> I was thinking server side CODA volutil dump.

I feel that file based backups, i.e. via a client,
are easier to handle - until they become too inefficient compared to
server side ones.

There are also discussions/recommendations somewhere else on the net,
e.g. when it concerns AFS backups.

Best regards,
Rune