On Tue November 16 2004 8:57 pm, Stephen J. Turnbull wrote:
> >>>>> "Jerry" == Jerry Amundson <jerry_at_pbs.com> writes:
>
>     Jerry> I have several GB of maildirs in a compressed tar
>     Jerry> file. When I try to untar (to venus on the SCM), it gets a
>     Jerry> ways before giving me "File too large" errors. But the SCM
>     Jerry> has plenty of space.
>
> "File too large" presumably means *file* too large.  Is there a chance
> that you've got a file (maybe a backup tar or something) > 100MB in
> there?  You aren't trying to copy the tarfile itself to Coda, are you?

mm, no. :-)

> The other likely candidate, since these are maildirs, and you get
> "quite a ways" but don't seem to have an intuition as to why it broke
> just *there*, is that you have a *directory* that is too large.  Since
> this limit is given in bytes (256K, IIRC), not dentries, I suppose
> that a somewhat imprecise "file too large" error might be issued when
> you run out of space for more entries in a directory.

Could be, I didn't think that would rear it's ugly head so soon, though.

[root_at_uhura vicepa]# find 0 | wc -l
2717
[root_at_uhura vicepa]# ls
0  FTREEDB

I selected the 2M per server max. if it matters...

>     Jerry> Can I bypass venus, or manipulate cache size somehow?
>
> No, you can't bypass venus.  There are no directories you can access
> without venus, it all lives in RVM, which is a BLOB.
>
> If it's a regular file, you just change the cache_blocks (or is it
> cache_size now?) entry in venus.conf (typically in /etc/coda), make
> sure your venus is sync'd up (cfs fr on each volume), and reinitialize
> venus.  If you want to ensure pre-primed cache for the users after
> rebooting venus, use spy and hoard.
>
> If it's a directory, fire up your editor of choice and start hacking
> Coda source.  Horrible, I know, but there you are; it's an unfortunate
> (in hindsight) design choice made many years ago.  Jan et al. have
> other priorities at the moment, although I'm pretty sure Jan has said
> that this restriction is on his "must go away someday" list.
>
>     Jerry> Also, how to I make sure the data is replicated to my
>     Jerry> second codasrv? Ie. venus on the second codasrv could
>     Jerry> really just be looking at the first.
>
> Shut down the first codasrv, and take a look via either venus, is the
> obvious brute-force approach.  I don't think looking in the server's
> container storage area will be very enlightening because the file
> names are all internally generated, but with "several GB" a du will
> tell you if you're in the ballpark or not.

Not in the ballpark, so far...
[root_at_monamie vicepa]# ls
FTREEDB

vice-setup on the second server told me:
----
"After that, there is still some configuration needed on the SCM before
this server can be started.

An entry for this host is needed in /vice/db/servers
Then all servers need to be shut down and restarted, as they need to
know about the new server.
After all that it _should_ be ok to start the new server and create
your first replicated volume."
----
Looks like createvol_rep has to specify both server - the second server 
cannot be added to an existing volume...?
http://www.coda.cs.cmu.edu/maillists/codalist/codalist-2004/6180.html

I'm just going to start over.