On Tue, Jun 14, 2005 at 03:47:16PM -0400, Greg Troxel wrote:
> My coda server is having hardware problems (a P6-200 from 1996!), and
> I'm about to upgrade it to a PIII-933 with a disk that's only 2 years
> old. The system is NetBSD 1.6.2.
If you can keep the server alive for a couple more seconds. The norton
dump/restore solution is definitely preferable, I used it before when
moving our servers to new hardware. However the norton dump works best
if you purge all backup volumes and other volume clones first, and you
need a running server for that.
The rvm dump file will contain the essence of what is stored in RVM, so
you do have to copy the file data in /vicepa separately. norton-reinit
then rebuilds everything in a new RVM data file (or partition) on the
new machine.
> I know I should have data, log, and vicepa on 3 spindles, but the new
> machine will have only one disk. (Plus, I care about reliability far
> more than speed.)
I think we typically have DATA and /vicepa on one drive and keep the log
separate. It isn't too hard to truncate, move the log later on.
$ rvmutl
* o LOG
* recover (or truncate or something)
* status (show show that it has been truncated)
* q
$ rm LOG
$ rvmutl
* i NEW-LOG 20M
* q
$ edit /etc/coda/server.conf
> I believe that names in /vicepa are referenced in RVM, not inode
> number, and that I should be able to just put LOG and DATA in vnds and
> use them as partitions. The comments at
> http://coda.wikidev.net/Optimizing_Coda_6.x make me believe that
> migrating rvm files and vicepa will work.
It might work, you could just try.
> Is there any real benefit to making LOG and DATA be bona fide
> partitions on the disk, rather than partitions backed by files?
Files are mmapped, so they end up dirtying less memory. Not sure if it
is all that more efficient on a BSD system though, since BSD has actual
unbuffered raw partition access, where Linux always uses the page cache.
> I could also make backups and restore them. One thing I'm not clear
> on is that restoring backups seems to make a new readonly volume, and
> I don't see how to turn that back into a rw volume like I want. Is
Correct, backups make read-only volumes and nobody has yet figured out
if it is just a matter of flipping some bit to make them read/write. The
alternative is to feed the volume dumps through codadump2tar to make
tar archives, but those don't contain ACL information.
Jan
