On Fri, Mar 07, 2003 at 05:40:47PM +0100, Steffen Neumann wrote:
> Jan Harkes <[EMAIL PROTECTED]> writes:
>
> > On Fri, Mar 07, 2003 at 10:35:25AM +0100, Steffen Neumann wrote:
> > > Jan Harkes <[EMAIL PROTECTED]> writes:
> > ... Syml
1036 bytes, returns 198, index = 0
> ...
>
> The error code 198 (unknown on Linux) is then propagated as the result
> of reintegration.
198 is EINCONS, inconsistency detected.
> As expected, /coda/test is now a dangling link:
>
> lr--r--r root test -> @7f01..
x27;s look suspicious after write reconnect in the
venus.log:
...
ClientModifyLog::COP1: (test), 1036 bytes, returns 198, index = 0
...
The error code 198 (unknown on Linux) is then propagated as the result
of reintegration.
As expected, /coda/test is now a dangling link:
lr--r--r root test -&
s codasrv) does not follow the masquerading rules when
initiating an SFTP transfer to a masquerading client (such as venus).
This happened when the server did a backfetch to get the file contents
for a store during reintegration. In my case, I have IPsec SPD
entries and firewall rules that limit
> > rpc2 params are not taking effect on the backfetch (are they
> > controlled by the server?)
>
> I believe so, although the server typically already has more lenient
> timeouts compared to the client, I believe the overall rpc2 timeout is
> set to 60 seconds instead of 15 sec..
This is al
On Wed, Sep 12, 2001 at 02:07:17PM -0400, Greg Troxel wrote:
> anoncvs is failing with ENOSPC type errors from the remote server.
I believe I got that one fixed, there was only 14MB free in /tmp on the
anoncvs server.
> rpc2 params are not taking effect on the backfetch (are they
> controlle
anoncvs is failing with ENOSPC type errors from the remote server.
I am running recent cvs code. I am losing on reintegration of
smallish (3-8K loses, 1K is ok) files.
The symptoms are that a bunch of packets get sent to the server and
get strung out in time by the modem. I don't see any
noticed that I was going disconnected during reintegration. 'cfs
cs' would go back to wd, and try to reintegrate. The bandwidth
estimates got way bigger than the 2500 that might be justifiable, and
the reintegration timed out. This happened repeatedly.
I then munged the bw estimation cod
On Mon, Feb 05, 2001 at 07:40:57PM +0100, Steffen Neumann wrote:
> Hi,
>
> I am fiddling around with a problem I have.
> The data in question is not vital, but I'd like
> to understand what's going on before it *is* vital.
>
> I have a volume that is write-only but connected,
> after the client
Hi,
I am fiddling around with a problem I have.
The data in question is not vital, but I'd like
to understand what's going on before it *is* vital.
I have a volume that is write-only but connected,
after the client was disconnected and I *know*
which files are in conflict. Volume state is:
On Mon, Jan 29, 2001 at 10:32:24AM +0100, Petr Tuma wrote:
> Hello,
>
> > There is reintegration, when a client sends a batch of operation to the
> > servers. And resolution where servers try to make sure their copies of
> > the data are in sync. Resolution is triggered
Hello,
> There is reintegration, when a client sends a batch of operation to the
> servers. And resolution where servers try to make sure their copies of
> the data are in sync. Resolution is triggered by a client who detects
> the differences in the version vectors when accessin
tegrating, on the client that caused that re-
> integration to occur knows what's happening.
There is reintegration, when a client sends a batch of operation to the
servers. And resolution where servers try to make sure their copies of
the data are in sync. Resolution is triggered by a cl
On 28 Jan 2001, at 15:14, Jan Harkes wrote:
> No way of telling. Only the initiation of a resolve shows in the codacon
> output of the client that triggered the resolution.
So, if a volume is reintegrating, on the client that caused that re-
integration to occur knows what's happening.
And only
On 25 Jan 2001, at 12:04, Jan Harkes wrote:
> In weakly connected (trickle-reintegration) mode, updates should be sent
> to the nearest server and server-server resolution is triggered. This
> creates greater window of opportunity for conflicts. The servers also
> lock any volu
According to Piotr K. Isajew:
>
>I'm trying to reintegrate a disconnected coda volume, but there is a
>problem:
>
>
>Any ideas?
>
What does the ctokens command say? Do you have a valid token? The
changes will only be reintegrated when the client has a valid token
from the server.
--
==
Finally the sequence of:
cfs truncatelog
cfs purgeml
helped.
Some data has been lost, but it seems to be working now. I wonder, if
there was any less brutal solution.
Peter.
On Fri, Dec 22, 2000 at 06:40:55AM -0500, Greg Troxel wrote:
> OK - you've got a problem more complicated than I know ho
Tokens are OK (it worked before). No firewalls (direct connection to
server (Ethernet)). But the console log is full of entries like:
volent::Reintegrate
volent::IsASRAllowed: returns 1
volent::DisableASR: disabling asr for 7f02
NotifyUserOfServerBandwidthEvent
volent::PartialReintegrate: (pk
Current blocks used are 694676
The partition has 256025 blocks available out of 3935419
Write-back is disabled
There are 80 CML entries pending for reintegration
pkinb:~$ cfs checkservers
Contacting servers .
All servers up
pkinb:~$ cfs reconnect /coda
pkinb:~$ cfs lv /coda
Status of vo
grate this volume ?
>
> thanks.
>
> cfs lv /coda/httpd/html/mrtg/
> Status of volume 0x7f04 (2130706436) named "s.mrtg"
> Volume type is Replicated
> Connection State is Disconnected
> Write-back is disabled
> There are 283 CML entries pe
004 (2130706436) named "s.mrtg"
Volume type is Replicated
Connection State is Disconnected
Write-back is disabled
There are 283 CML entries pending for reintegration
On Thu, Aug 24, 2000 at 04:04:00PM -0400, root wrote:
> I am still having reintegration problems.
> Here is part of /usr/var/log/messages (Redhat 6.2) after rebooting.
> Notice the warning about the "weird fid".
Those weird fids appear during a repair session when t
Bill Gribble <[EMAIL PROTECTED]> wrote:
>
> In general, is there any way to say "Force synchronization of all
> volumes right now, and I mean it?" Seems like reintegration messages
> pop up VERY slowly when changes are happening fairly rapidly. I'd
> like cl
inconsistent and need to be
fixed with repair. Sometimes repair works, sometimes it doesn't.
Also, I get a lot of this "Cannot create regular file: Connection
timed out." This is a pain in the butt. What's going on?
In general, is there any way to say "Force synchronizati
[EMAIL PROTECTED] said:
| cfs disconnect
| cfs reconnect
Yes, this is a known problem, cfs disconnect puts a software filter in
the rpc2 layers, but reconnect fails to clear it.
Use 'filcon clear -c localhost' to get rid of the filter without
restarting venus.
[EMAIL PROTECTED] also
Hi all,
I am testing Coda 5.2.2 on Redhat 6.0. Everything seems to work except of
reintegration. I have a client with kernel 2.2.9 (also Redhat 6.0, ie.,
glibc 2.1) with /coda mounted. If I issue the following commands:
cfs disconnect
cfs reconnect
the connection to the Coda server is
26 matches
Mail list logo
