On Tue, May 22, 2018 at 8:30 PM, Davor Josipovic wrote:
>> Now that is interesting. 40k doesn't seem to be such a large amount of
>> data for modern computers. Very slow and fragmented hard drive? Or perhaps
>> there's something else going on that is manifesting this way?
>
> The HDD is indeed on
On Tue, May 22, 2018 at 2:36 PM Davor Josipovic wrote:
> > Now that is interesting. 40k doesn't seem to be such a large amount of
data for modern computers. Very slow and fragmented hard drive? Or perhaps
there's something else going on that is manifesting this way?
> The HDD is indeed on the s
> Now that is interesting. 40k doesn't seem to be such a large amount of data
> for modern computers. Very slow and fragmented hard drive? Or perhaps there's
> something else going on that is manifesting this way?
The HDD is indeed on the slowside, and together with low memory...
But I think t
> Now that is interesting. 40k doesn't seem to be such a large amount of data
> for modern computers. Very slow and fragmented hard drive? Or perhaps there's
> something else going on that is manifesting this way?
The HDD is indeed on the slowside, and together with low memory...
But I think t
> Now that is interesting. 40k doesn't seem to be such a large amount of data
> for modern computers. Very slow and fragmented hard drive? Or perhaps there's
> something else going on that is manifesting this way?
The HDD is indeed on the slowside, and together with low memory...
But I think t
On Mon, May 21, 2018 at 4:05 PM Davor Josipovic
wrote:
>>I have finally found the culprit. By coincidence, I had the same
>>configuration running on two servers, one backed with a SSD, the
>>other with a HDD.
>>
>>The same commit worked on the SSD-backed server, and always failed
>>on the HDD
On Mon, May 21, 2018 at 4:05 PM Davor Josipovic wrote:
> I have finally found the culprit. By coincidence, I had the same
> configuration running on two servers, one backed with a SSD, the other with
> a HDD.
>
> The same commit worked on the SSD-backed server, and always failed on the
> HDD one
I have finally found the culprit. By coincidence, I had the same configuration
running on two servers, one backed with a SSD, the other with a HDD.
The same commit worked on the SSD-backed server, and always failed on the HDD
one with the described error.
Monitoring the process revealed that af
I have finally found the culprit. By coincidence, I had the same configuration
running on two servers, one backed with a SSD, the other with a HDD.
The same commit worked on the SSD-backed server, and always failed on the HDD
one with the described error.
Monitoring the process revealed that af
I have finally found the culprit. By coincidence, I had the same configuration
running on two servers, one backed with a SSD, the other with a HDD.
The same commit worked on the SSD-backed server, and always failed on the HDD
one with the described error.
Monitoring the process revealed that af
Davor Josipovic writes:
> You make the PID sound very important, and with good reason too! I
> just went back through the logs to make sure that I didn't mess up the
> PID before posting. I didn't. In each case, the PID was
> different. This might explain the time difference.
The Subversion clie
> I am at a bit of a loss. Something appears to be deleting files from
> underneath Subversion. The file that goes missing while processing the
> DELETE request was almost certainly present when we started processing
> the DELETE, since readdir() returned its name, but a very short time
> later w
> I am at a bit of a loss. Something appears to be deleting files from
> underneath Subversion. The file that goes missing while processing the
> DELETE request was almost certainly present when we started processing
> the DELETE, since readdir() returned its name, but a very short time
> later w
> I am at a bit of a loss. Something appears to be deleting files from
> underneath Subversion. The file that goes missing while processing the
> DELETE request was almost certainly present when we started processing
> the DELETE, since readdir() returned its name, but a very short time
> later w
Davor Josipovic writes:
>> Are you running Linux or Windows? Is the disk local or networked?
>
> Server is Debian 9.3. Disk is mounted through fstab with options
> noatime,nodiratime,data=ordered,nofail.
>
>> Do you have some other process running that mointors the filesystem or
>> the repositor
> Are you running Linux or Windows? Is the disk local or networked?
Server is Debian 9.3. Disk is mounted through fstab with options
noatime,nodiratime,data=ordered,nofail.
> Do you have some other process running that mointors the filesystem or
> the repository? Does it actively delete files?
> Are you running Linux or Windows? Is the disk local or networked?
Server is Debian 9.3. Disk is mounted through fstab with options
noatime,nodiratime,data=ordered,nofail.
> Do you have some other process running that mointors the filesystem or
> the repository? Does it actively delete files?
> Are you running Linux or Windows? Is the disk local or networked?
Server is Debian 9.3. Disk is mounted through fstab with options
noatime,nodiratime,data=ordered,nofail.
> Do you have some other process running that mointors the filesystem or
> the repository? Does it actively delete files?
Davor Josipovic writes:
>> Do you see the DELETE in the log after the failed MERGE? Was there an
>> error?
>
> The apache2 log I posted is the whole log for that day as far as I
> recall. There was nothing else. You see the DELETE error before the
> MERGE error. I think that is due to a timing i
dav:error] [pid 2966] [client
>> X.X.X.X:61712] An error occurred while committing the transaction. [500,
>> #160014]
>> [Sat Feb 10 03:25:30.643003 2018] [dav:error] [pid 2966] [client
>> X.X.X.X:61712] Reference to non-existent node '_1bqk.0.t463-e8'
dav:error] [pid 2966] [client
>> X.X.X.X:61712] An error occurred while committing the transaction. [500,
>> #160014]
>> [Sat Feb 10 03:25:30.643003 2018] [dav:error] [pid 2966] [client
>> X.X.X.X:61712] Reference to non-existent node '_1bqk.0.t463-e8'
dav:error] [pid 2966] [client
>> X.X.X.X:61712] An error occurred while committing the transaction. [500,
>> #160014]
>> [Sat Feb 10 03:25:30.643003 2018] [dav:error] [pid 2966] [client
>> X.X.X.X:61712] Reference to non-existent node '_1bqk.0.t463-e8'
8] [dav:error] [pid 2966] [client
>> X.X.X.X:61712] An error occurred while committing the transaction. [500,
>> #160014]
>> [Sat Feb 10 03:25:30.643003 2018] [dav:error] [pid 2966] [client
>> X.X.X.X:61712] Reference to non-existent node '_1bqk.0.t463-e8' in
&
.X:61712] An error occurred while committing the transaction. [500,
> #160014]
> [Sat Feb 10 03:25:30.643003 2018] [dav:error] [pid 2966] [client
> X.X.X.X:61712] Reference to non-existent node '_1bqk.0.t463-e8' in
> filesystem '/mnt/vc/svn/repo/db' [500, #160014]
&
/svn/repo/repofolder". [500, #0]
[Sat Feb 10 03:25:30.642889 2018] [dav:error] [pid 2966] [client
X.X.X.X:61712] An error occurred while committing the transaction. [500,
#160014]
[Sat Feb 10 03:25:30.643003 2018] [dav:error] [pid 2966] [client
X.X.X.X:61712] Reference to non-existent node
/svn/repo/repofolder". [500, #0]
[Sat Feb 10 03:25:30.642889 2018] [dav:error] [pid 2966] [client
X.X.X.X:61712] An error occurred while committing the transaction. [500,
#160014]
[Sat Feb 10 03:25:30.643003 2018] [dav:error] [pid 2966] [client
X.X.X.X:61712] Reference to non-existent node
on
>
> I assume this is the correct place to report?
>
> I concerns the error 160014 "Reference to non-existent node". Some changes I
> can not commit through https://, but I can commit directly through the
> file:// protocol.
>
> Any idea's?
Yes, this is the
"Reference to non-existent node". Some changes I
can not commit through https://, but I can commit directly through the file://
protocol.
Any idea's?
28 matches
Mail list logo
